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FOREWORD 

This document, adapted from a Master's thesis in Electrical 
Engineering, is being jointly published by two research activities at 
M.I.T., Project MAC and the "Innovative Resource Planning" Project. 

Project MAC is an M.I.T. interdepartmental laboratory for 
computer research and development involving faculty and students from 
the Departments of Electrical Engineering and Mathematics and the Sloan 
School of Management. The name MAC is an acronym derived from several 
titles: man and computers, machine-aided cognition, and multiple-access 
computers. The broad goal of machine-aided cognition implies the 
development of new ways in which on-line use of computers can aid people 
in their creative work, whether it be research, engineering design, 
management, or education. 

The research project, "Innovative Resource Planning in Urban 
Public Safety Systems," is a multidisciplinary activity involving 
faculty and students from the M.I.T. Schools of Engineering, 
Architecture and Urban Planning, and Management. The administrative 
home for the project is the M.I.T. Operations Research Center. The 
research focuses on three areas: 1) evaluation criteria, 2) analytical 
tools, and 3) impacts upon traditional methods, standards, roles, and 
operating procedures. The work reported in this document is associated 
primarily with category 2, in which a set of analytical and simulation 
models are developed that should be useful as planning, research, and 
management tools for urban public safety systems in many cities. 
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ABSTRACT 



The hospital emergency room is a complex system having many 
interrelated factors contributing to its operation. The emergency room 
administrator has limited control ever certain of these factors: 
numbers of beds, nurses, doctors, x-ray units; for example. Other 
factors such as patient arrival rates and demands made upon available 
resources are largely uncontrollable. One of the main problems facing 
the emergency room manager is to find a reasonable balance among the 
many factors over which one has control in the face of a range of values 
of the factors over which little control is possible. 

A computer program has been designed which uses computer 
graphics and interaction with the user to create a flexible modeling 
environment for analysis of hospital emergency rooms. In projects 
involving analysis of public systems, it is especially important that 
close communication be maintained between the public administrator and 
the analyst. Tools of the type which concern the present research can 
make a significant contribution towards this end. 

The emergency room was chosen as the basis for the research for 
two reasons: First, the author had been a member of a team which 
performed an analysis of the Cambridge Hospital emergency room in 
Cambridge, Massachusetts, and therefore was somewhat familiar with the 
emergency room system and factors relevant to its analysis. Second, the 
emergency room is a system which in many hospitals is rapidly 
approaching a crisis: like the medical care system as a whole, the 
emergency room is experiencing profound changes in the demands being 
made of it. Patient arrival rates are increasing at an exponential 
rate. For many, the emergency room has become the primary source of 
medical care. Thus the very role of the emergency room is becoming 
unclear. The rapid changes in volume and nature of demand being 
experienced by the emergency room suggest that time invested in analysis 
and planning of the system would be well spent. 

The program, the Tool for Interactive Graphical Emergency Room 
Simulation (which, for ease of discussion, is referred to as TIGERS) is 
a simulation-based modeling environment which has been implemented on 
the PDP-10 computer of the Programming Technology Division of Project 
MAC at H.I. T. This first effort, although general in scope, is based 
upon the emergency room at Cambridge Hospital. A preliminary model 
based upon this emergency room has been implemented. Valuable feedback 
has been obtained from Dr. Peter ilogielnicki there, and it is expected 
that other doctors in the Boston area may soon try out the system as 
well. The main thrust of the research is being concentrated not on 
designing a highly accurate model of a particular emergency room, but 
rather on development of a tool which can be used for such a purpose. 

The actual implementation of the simulation within TIGERS 
involves the design of a model and the translation of the model into 
data bases and events. The task is made somewhat easier in that TIGERS 
provides all major data bases and several utility subroutines. The 
graphics updating is automatic, and routines are provided which make 



trivial the creation of light buttons for changing any relevant 
parameters. 

The hardware upon which the present system is implemented is 
currently too expensive for practical application in most situations, 
but graphics tecfce» lew is developing rapidly an* is fast entering the 
realm of practicability for smaller installations. Both to the analyst 
and to the public administrator, the medium P o pr e soo t» a potentially 
useful means of making simulation models more intuitive and easier to 
understand. 
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CHAPTER I : INTRODUCTION TO THE HEDICAL CARE PROBLEM 

1.0 The Crisis in the Medical Care Sector 

The health care industry has become ,|he second largest industry 
in the United States. In 1970, Americans spent 67.2 billion dollars, 
6.9 per cent of the Gross National Product, on their health. And the 
industry is fast growing: between 1966 and 1970, health expenditures 
increased at an average annual rate of 12.3 percent, compared to a 
growth rate of 6.3 percent fur the economy as a whole. The Department 
of Health, Education, and Welfare has projected a figure of 105 billion 
dollars for fiscal year 1974 pi, and expenditures in the health 
enterprises in the United States are projected to reach between 156 and 
189 billion dollars by the end of the current decade. Thus our society 
will be spending between 8 and 9.8 percent of the Gross National Product 
for health. If present trends continue, the health establishment may 
well be the nation's largest industry, in terms of manpower and 
expenditures, by 1980. [2] 

Unfortunately, even our present vast expenditure of over $350 
per capita annually does not ensure a high level of medical care in the 
United States. Rate of infant mortality is lower in twelve other 
industrial countries. Hen in seventeen other countries J4ye. longer than 
Americans do, and women live longer in ten. There is a growing 
consensus in the United States that the medical care sector, while 
continually costing more, is not performing its functions well for all 
those who could benefit by them; a nearly ubiquitous view that there is 
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a health care "crisis." Between 1960 and 1971, costs of hospital care 
climbed more than SO percent, compared to a 31 percent increase in the 
consumer price index. A day in a hospital cost S35 in 1960 and $75 in 
1971. [3] A typical company sponsored health insurance plan, including 
full hospitalization and surgical benefits for a family, cost $550 in 
1971, more than double the amount of just five years before. 

The symptoms of the crisis are all too clear -- skyrocketing 
expenses and inadequate care for a significant sector of the population 
-- but the cure is not so easily seen. Berk i and Heston articulate the 
nature of the problem: "The multiplicity of proposals for the cure of 
this 'crisis' in terms of delivery, organization, financing, and control 
is evidence that dissatisfaction with the performance of the medical 
care sector has reached the status of a politicized social problem. As 
in other complex diseases, while there is agreement that something is 
drastically wrong, there is no consensus on either the diagnosis or the 
therapy." [4] 

The fact that we spend such vast amounts on health care, and the. 
fact that health care expenditures are rising at a rate far out of 
keeping with the rest of the economy , lead one to believe that we are 
not allocating our resources, i.e. bur health dollars, as wisely as we 
might. Dr. David D. Rutstein expressed this belief in his book. The 
Coming Revolution in Medicine: "The hallmark of our present haphazard 
system of medical care Is lack of efficient systematic allocation of 
resources to meet the public need. Implicit is a lack of planning which 
really reflects the pitiful inadequacy of research on the provision of 
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medical care. Indeed our blind faith in the infallibility of the 
physician has made it seem in the past as if research on medical care 
were unnecessary." [5] Essentially what We have done has been to leave 
the allocation and distribution of resources almost exclusively to the 
marketplace. Apparently the marketplace has failed us in this case, as 
we find ourselves caught in a burgeoning spiral of ever increasing 
expense that buys little significant improvement to the system. 

Our lack of planning is catching up to us. Even though our 
medical care system has perhaps never been run nearly as efficiently as 
it might have been, only in the last decade has the situation started to 
get out of hand, generating the so-called crisis that is now all too 
manifest. The problem was first recognized as early as 1933. In that 
year the classic Lee-Jones study, undertaken under the auspices of the 
Committee on the Cost of Medical Care (CCNC) pointed out that "The 
problem [the provision of good medical care] will not solve itself 
through the operation of undirected economic forces." [6] People, 
however, were not yet ready to listen. 

Thirty-five years after the publication of the Lee-Jones study, 
the report of the National Advisory Commission on Health Manpower was 
issued. This commission was established because the problem- turned- 
crisis could no longer be overlooked. Costs were rising out of all 
reasonable proportion compared to the rest of the economy; there was 
insufficient manpower to meet the requirements of the system structured 
as it was. The commisson reported essentially the same problems as 
reported thirty-five years earlier. The report very clearly proclaimed 
a health crisis, pointing out: 
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The crisis, however, is not simply one of numbers. It is 
true that substantially increased numbers of health manpower 
will be needed over tine. But if additional personnel are 
employed in the present manner and within the present 
patterns and systems of care, they will not avert, or even 
perhaps alleviate, the crisis. Unless ?e improve the system 
through which health care is provided, care will continue to 
become less satisfactory, oven though, there ^•.passive 
increases in cost and in numbers of health personnel. [7] 

We are faced not with a shortage, but with a problem of mlsal location. 



1.1 Alleviating the Problem 

It is not surprising that the concept of efficiency is the 
mainstay of medical reformers. Here efficient operation would 
presumably provide more services for more people, limit the cost to 
third parties, and similarly limit the skyrocketing costs to patients, 
insurance companies, and the government. The government, which pays two 
fifths of the nation's medical bills, should be especially interested in 
improving efficiency, since it would retard inflation as well as costs. 
Doctors too would benefit from more efficient operation. "By increasing 
his productivity, he can see more patients, respond to growing patient 
criticism of the availability of doctors, increase his earnings, and 
help more people." [8] 

Optimizing such an incredibly complex system ^s our whole 
medical care system is a problem of huge magnitude. Indeed, optimizing 
it is probably impossible, but even making significant improvement is an 
awesome task. Where do we begin? The problem really exists at several 
levels, and the task needs to be addressed at each one. 
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At the outermost or most "macro" level, we are faced with broad 
political and social questions. Who should pay for medical care? How 
should the overall system be structured? Can everyone have a family 
doctor, and if not, where does he go for his primary medical care? What 
about medical centers? How should they be organized? By neighborhood? By 
region? Should doctors be paid on a fee basis, or are there other 
structures of payment which might reduce unnecessary surgery and be more 
conducive to other "more efficient" treatment? 

In the middle levels are questions which, although not as 
political or social, still concern broad issues that will affect the 
very nature of the medical care system- For example: should all 
hospitals be general, equipped and staffed to handle a wide range of 
needs; or should a network of specialized or semi-specialized centers be 
set up? How do we evaluate the utility of various possibilities? 

Finally, at the most "micro" levels, we face such questions as 
how to run the facilities themselves. How do we Staff the intensive 
care unit? How many doctors do we need? where can paramedical personnel 
be used, and where is a doctor essential? Where can we use machines? 
How many beds do we need such that the probability of all being full is 
below a given level? 

Thus we see that the decisions involved in planning a more 
efficient health care delivery system span a wide range of positions in 
the decision making hierarchy -- from the highest levels of government 
to administrators of individual medical centers. It is these people who 
are called upon to make the decisions which will hopefully bring our 
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medical care system to an improved level of operational efficiency. As 
we stated earlier, their task is not easy. 

1.2 Operations Research 

A body of knowledge and analytical methods known as "operations 

research" is evolving, which is directly applicable to certain, aspects 

of the medical care problem. At each level of the hierarchy, a basic 

concern of decision makers is the allocation of resources so as either 

to maximize the accomplishment of the stated objectives with given 

resources or to minimize the resource costs of achieving the given 

objectives. Operations Research (hereafter sometimes abbreviated O.R.) 

is concerned with realizing such allocation procedures . Dr . Rutstein 

discusses a bit of the history of O.R., and points out hew O.K. is 

beginning to be applied in the health care sector: 

Historically, operations research was first used in the 
deployment of troops and materiel in World War II. The 
success of operations research in military logistics led to 
the extension of its use to industrial production problems 
in war industry, then to industrial premlem*f|«ijgeneial» to 
business management, and to economic planning. How it is 
being applied to public health and medical care. In a 
policy statement on operations research prepared for the 
World Health Organization with Professors Hareek- Paul 
Schutzenberger and Hurray Eden, we pointed out that O.R. is 
useful in the kinds of major decisions that frequently face 
the medical administrator. They are as follows: 

1. How does one assess the relative needs for, and the 
values of, alternative values that must draw^upon limited 
resources in funds, material, and trained manpower? 

2. How shall available resources be best allocated and 
applied once a decision en priorities has been made? £9] 
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1.3 Our Misuse of Available Resources 

Although it is only a beginning, several studies have been made 
or are now underway investigating the problems of the medical care 
sector, at least at the broadest levels, i.e. addressing the important 
political and social questions. This is indeed encouraging -- but this 
type of planning is necessarily relatively long range planning. At the 
level of hospital administration — the level where the crisis is being 
most acutely experienced -- very little has been done, although the 
field is ripe for applications of O.R. It is well known that many of 
today's hospitals have a surplus of hospital beds while their clinics 
are becoming more congested than ever. Such statistics suggest that we 
would do well to invest more time in questioning our present patterns of 
hospital management. The skyrocketing costs of hospital care, along 
with the ever increasing difficulty of getting an appointment at a 
hospital clinic, is evidence that hospitals, rather than searching for 
more viable systems, have been trying to cure themselves only by pouring 
more money into the already existing one. The situation is unfortunate 
because it is really in the hospital where the crisis must be confronted 
first; it is there that first aid can be administered to the ailing 
medical care system. 

There are really two aspects of the problem faced by the O.R. 
researcher in the medical care field, or for that matter in any field of 
public administration. First is the relatively straightforward problem 
of devising relevant analytical methods and techniques. Second is the 
more subtle problem of getting them implemented. 



22 

Administrators are making increasing use of these analytic 
tools, but not nearly as much as might be expected. The answer to the 
question of why not is complex. First there is a problem of hesitancy 
to leave a system that works, even poorly, for a system which is 
untried, or at least unknown to the administrator. People are uncom 
fortable in unfamiliar territory. There is security in "the way we've 
been doing it," and we are not inclined to set off down dark paths that 
we do not know and therefore cannot really trust. It is a known aspect 
of human nature that administrators are often reluctant to implement, or 
even investigate, any changes to an existing system until action is 
forced by a complete failure of the system. Another common obstacle to 
acceptance of more rigorous analytical methods is misrepresentation: It 
is not uncommon for the decision maker to be exposed to analytical 
techniques, but led to believe, either by overzealous analysts or simply 
by wishful thinking, that these new methods are being presented as a 
panacea. Then he either immediately sees or later discovers that they 
are not, and he loses faith in them altogether. This communications gap 
between the analyst and the administrator is destructive — the 
administrator presented with a "solution," only to be disillusioned, Is 
naturally going to lose any faith he might have had in the analytical 
techniques. Operations research does not offer an instant solution, but 
it does offer a powerful set of quantitative tools. 

Another reason that O.R. is not being employed to best advantage 
in the medical care sector is that hospital administrators are often 
physicians, who, not surprisingly, rarely have strong backgrounds in 
management. There is, of course, no reason why they should — 
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physicians are specialists. The unfortunate aspect of the system is 
that they are forced to be big business administrators as well. 

1.4 Motivation for Present Research 

The research of this report was undertaken as a step towards 
bridging the gap between the administrator and the analyst. The goal of 
the research was to use the medium of computer graphics to develop an 
analytical tool which might be used by a hospital administrator, and 
which would improve communication and encourage co-operation between the 
administrator and the analyst. 

One of the reasons for the communications gap is that 
quantitative analytic techniques are often highly technical, and 
although the administrator understands the statement of the problem he 
is often forced to view the technique itself as a black box which is 
open only to the analyst. There is a need for tools which lend 
quantitative insight into complex problems while avoiding the necessity 
of reams of computer printout or formidable looking sets of equations. 
Computer graphics, which is only now beginning to be widely used, offers 
a possible answer to this need. 

This research is intended as a first step in the development of 
such tools. 
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CHAPTER II: THE HOSPITAL EMERGENCY ROOM 

2.0 Introduction 

The hospital is a large, complex system comprising numerous 
smaller subsystems. It was decided that in light of the goals of this 
research project, more would be accomplished by concentrating the 
research effort, at least at first, on a representative subsystem of the 
hospital. 

It is worthwhile, therefore, to examine one of these subsystems 
in greater depth: a facility found in diverse forms and sizes but 
common to most hospitals is the emergency room (hereafter sometimes 
abbreviated "E.R."). In a sense a microcosm of the medical care system 
as a whole, the emergency room is experiencing profound changes in the 
demands being made of it. The number of patients crowding into 
emergency rooms has tripled in the past fourteen years, from 18 million 
in 1958 to 44.1 million in 1968 to an estimated 60 million in 1972. [1] 
The very role of the emergency room is becoming unclear. A study of 
patients attending one emergency ward found that 1 It appeared to be the 
primary source of medical care Tor at least one fourth of its 
patients. [2] 

Dr. Reinald Leidelmeyer, a co-founder of the American College of 
Emergency Physicians, cites two reasons for the avalanche of emergency 
room patients. 
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"In the first place, the American people have become enormously 
mobile. It is a rare occurrence indeed that a newcomer to an area takes 
the time to find himself a physician before he really needs one. 

"Secondly the family physician — who had been the focal point 
of initial medical care through the ages — became mere and more 
scarce." 

Thus, points out Dr. Lei deleaver, the patient chooses to wait a 
few hours in the emergency ward rather than a few weeks for an 
appointment with his doctor. [3] 

The rapid changes in volume and nature of demand being 
experienced by the emergency room suggest that time invested in analysis 
and planning of the system would be well spent. The emergency room is a 
complex system, and managing it effectively is net simple : the system 
has many variables (e.g. number of doctors, number ©f beds, number of 
nurses, patient arrival rate, etc.); numerous complex trade-offs (e.g. 
an efficient E.R. must strike a balance between ■.aimjber s .-.of beds, 
doctors, and nurses); and is highly stochastic in nature (it can be 
empty at one moment and overloaded five minutes later). Yet with all 
this complexity, most emergency rooms are planned, organized, and 
staffed without, the aid of available analytic technique* • D«v«lopaient 
of quantitative tools might aid the hospital manager in several ways; 
for example; 

1. improvement of staff ing patterns 

Z. evaluating proposed changes in fecilites or personnel 

3. designing new facilities 

4. estimating future demands on the system, and the 
system's ability to handle them. 



L^&fe^fc?**-^-** 



in: 



27 



More specifically such quantitative tools Bight be used as aids 

1. reducing patient waiting tiara 

Z. improving doctor utilization 

3. reducing unneeded tine that the patient spends in the 
treatment facility. -.^av. <■■.&■,-...■■. 

2.1 An Interactive Graphical Simulation 

The primary research of this report involves the design and 
implementation of an interactive program for simulation of a hospital 
emergency room. The emergency room presents an excellent focus for our 
study, because it is relatively small, yet quite complex, and it can 
probably benefit significantly from the use of analytical techniques. 
Recall from Section 1.4 that the purpose of this research effort is to 
use the medium of computer graphics to develop an analytical tool which 
might be used by a hospital administrator, and which could improve 
communication and encourage c©*H*peratf#n ^ tAtwee^^l^ administrator and 
the analyst, Her* Kas been undertaken towards this end by the author at 
the Programing Technology Division l *P ff.&4*k Project ItAC. A program 
has been written employing th*i»DP~W computer, th« Evans *nd Sutherland 
display prtK:e*serv*uid^*4s0^ia«e^ supporting -1*t4Mm&*mriH9i*- : b¥-lb* 
Programing Technology Division. The program i* the Tool for 
Interactive Graphical Emeroeitcy Rooa Simulation, which, for simplicity 
and ease of discussion, we call TIGERS. 
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2.2 Cambridge Hospital 

It was decided that TIGERS, at least at first, would be based on 
a specific eaergency rooa. Although generality is unquestionably 
desirable, the idea of graphical simulation is best investigated first 
by applying it to a relatively specific case. Once initial 
investigations are complete, work can begin on making the program aore 
general . 

The TIGERS systea is based on the eaergency rooa at the 
Caab ridge Hospital in Caabridge, Massachusetts . It is an eaergency rooa 
in the medium size range, with about one hundred patients per day 
arriving for treatment. In the next sections we shall atteapt to 
describe the Caabridge Hospital Eaergency Rooa, and give the reader a 
feeling for the facilities, the staffing patterns, and the types of 
patients who arrive there for treatment. 

2.2.1 Rele in the Community 

Tha purpose of: 4h* Cambridge Hospital Eaergency Rooa ( hereaf ter 
soae times abbreviated CHER > is to provide prompt, h44lh |Ht*Hty medical 
can on a twenty-four hour be^is ta all «4«q arriva there. Although the 
term "eaergency rooa" usually iaplies a piac* wh^ handles only very 
serious medical problems, the, enerflency rcwa a* Caabridge Hospital could 
be classified as a type of aabulatory clinic. Ifee grretet majority of 
people seeking service at the eaergency rooa, do no* npod Immediate 
aedical attention. In fact, only about fj^ parent ^^th^» arriving 
patients at CHER are what one would normally call "emergencies," and 
only about one percent are pre-emptive eaergencies requiring the entire 
E.R. staff. (This situation is not unique to Cambridge Hospital.) 
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Especially for the poorer sections of Caabridge, the CHER takes 
the place of the old style faaily physician. This is not unusual for 
hospitals in Riddle or lower class areas. In the clinic at the 
Cambridge Hospital, and at other clinics in the area as well, it is 
often weeks before one can get an appointment. It is not surprising 
that the faster paced emergency room is often used instead. 

Figures 2-1, 2-2 and 2-3 present a picture of the type of 
patient entering the CHER. Figure 2-1, the diagnosis of eaergency room 
patients, shows that most patients have Minor complaints such as 
superficial sprains, while the true emergencies, such as cardiac arrest 
or naj or fracture, make up only a few percent of the pa* ten**. Figures 
2-2 and 2-3 shew that few patients (less than ten per cent) are brought 
to the CHER by ambulance (and many of ^wmiWmW^m^'plt^^^p^iMnts 
transported from nursing homes), while e»st are able to come to the 
hospital by themselves. Finally, less than ten per cee£ g ef { Jthe patients 
arriving at CHER have problems serious enough to result in >their being 
admitted to the hospital, and many of Oiese tf« pef ceet - ; ere not true 
emergencies. 

2.2.2 Physical Plant 

A diagram of the CHER is given in Figure 2-4. A typical patient 
walks into the eaergency rooa entrance (1) and immediately registers 
with the receptionU^ He fUls out th^,r«flifltr*t^on fora, which 
becomes his record of emergency room treatment. Then he sits in the 
waiting rooa (3) until called by a nurse, who brings the patient to one 
of the five beds in the general treataent rooa (6). (He aay be assigned 
to a chair if the complaint is minor.) In the general treatment room the 
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Superficial injury -- strain , sprain, contusion 



5 ? 
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Upper respiratory infection -- viral syndrome 



Lacerations, bites, and punctures 
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Symptoms and i I (-defined conditions 
Skin disorders 
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Minor fracture 
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Dx not specified 
Lower Respiratory Infection 
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Urinary tract infection 
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Major fracture 
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MEDjCAL 

PEDIATRIC 

ICU 

PSYCHIATRY 0.2% 
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MEDICAL 2.0% 

SURGICAL 5.1% 

PEDIATRIC "0.8% 
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NOT SPEC D 12.0% 



Figure j2-2. Pat&nt Deposition 
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Patient Conveyance 
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patient is seen by a doctor (when one becomes available), who determines 
the required course of diagnostics and treatment. Very often the 
patient requires rather lengthy "non-doctor treatment " such as 
laboratory tests, x-rays, treatment by a nurse, etc. When the patient 
has been treated* he is released; and he either is admitted to the 
hospital proper or exits through the emergency room fntrance (which is 

also the exit) (1), 

A patient who is brought to CHER l»y an ambulance or other, 
emergency vehicle (usually on a stretcher) enters the emergency room 
through the amjbulance entrance U3). In this manner he can enter CHER 
without passing through the waiting room or filling out a form. The 
E.R. staff is generally informed" of the impending Arrival of such a 
patient about five minutes before the vehicle actually yets to the door, 
which gives $hem time to prepare for dealing w^th a •i^al^ emergsncy. 
This is made possib|e by three direct telephone lines ,JM) to the 
police, fire department, and ambulance services. 

Immediately adjacent to the mala treameat room is the shock room 

• i-- v*-i-<T> -: .I'i^Jnrnv; -<:'f. T" o^o-fir-- ?<*! , sir- : -* -■"-.> ,-cr - : ^J to ?■ 

(8), which is used for very serious cases such as cardiac arrests. It 
is the shock room that plays the role that most people normally 
associate with that of the emergency room. In this room are all 
necessary supplies for treating a cardiac arrest or other very serious 
emergency;, every effort is made to keep this room clear for such 
occurrences. The only other use of this room is for obstetric- 
gynecological (Oi-GYN) cases; the bed for pelvic examinations is in a 
corner of the room, away from the other equipment. 
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Any patient under fourteen years old is considered a pediatric 
case and is taken to the pediatrics room (7) instead of the m in medical 
treatment rooa. the pediatrics rooa contains three beds and a desk and 
is used exclusively for persons under fourteen. 

Other rooms in the emergency rooa are a small staff lounge (10), 
a small laboratory (11) where doctors can perform simple tests such as 
urinalysis, a medical supplies closet (12), and the orthopedic room 
(15). This last room is actually the hospital's orthopedic clinic and 
Is not a part of the emergency room proper. Whin not being used as a 
clinic, however, it is used for E. ft. psychiatric patients, both as a 
waiting room and as an interviewing room. Also, it is used for patient 
interviews with such people as social workers and Staff '''members of the 
alcoholic detoxification program. 

the general medical room (6) contains five beds (each made 
private by surrounding curtains), a number of chairs for patients who 
don't need a bed, a sink, various medical supplies, and a single desk 
for the doctors' use. The records of the patients being" treated are 
kept at this desk. The paper work (i.e. writing up patient records) is 
done mostly at this desk; therefore a telephone and the laboratory and 
x-ray requisition forms are also located here. 

Filling in the diagnosis and treatment on a patient's eaergency 
room treatment record can also be done at the main desk (4). fledical 
reference books are there, as well as a regular telephone (in addition 
to the three special lines), the main desk is used largely for 
research, telephoning, and consulting with the staff doctor assigned to 
assist in the emergency rooa. 
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2.2.3 Staffing 

The CHER staff consistsof a receptionist , two or three nurses, 
one or two interns, a staff sector; ahdi at various tiae s, medical 
students, nurses* aides, orderlies, and paramedical students. The 
staffing pattern is shown in Figure 3-2, along with the average nuaber 
of arrivals to CHER, by hour of the day. 

The staff ing pattern is designed' to* dial* with* the* tine-dependent 
arrival rate of patients to the emergency roemv The, high demand hours 
are 9 a. a. to 11 p.*-.; from 11 a.m. to 7 p. ■., daring which tiae the 
average patient arrival rate Is about five per hour? ther% are always a* 
least two Interns and a staff doctor, Iftso dar4a#lh%«day there are 
three nurses on duty. Theoretically tWfr Mltirn%J#i^*ld«ftth* i>r*IBa!ry 
medical care, while the role of the staff doctor is that of a consulting 
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physician. (When the room begins to become overcrowded, however, the 
staff doctor also provides priaary care.) In practice, however, some of 
the staff doctors, while still acting as consultants when needed, engage 
in priaary patient treatment all the tiae. In such cases there are 
effectively three full-tiae doctors in the eaergency rooa. 

During the evening the arrival rate begins to taper off, until 
at night the rate is greatly reduced, on the order of one patient per 
hour. At night only one intern and one nurse are on duty. Generally 
froa 7 p.m. to 1 a.a., a "aoonlighter" is also employed; he is a staff 
doctor or a resident whose role is analogous to that of the staff doctor 
during the day. From 1 a.a. to 7 a.a., however, the only doctor on duty 
is the one intern on the "night shift." 
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It is the CHER nurse who first sees the entering patient.. She 
assigns the patient a bed and Measures his vital signs? and then assists 
the doctors in working with the patients, watching thea» obtaining 
specimens* filling out lab and x-ray reouisitions, and various other 
duties. 

Since the Cartridge Hospital is a teaching hospital, it has an 
arran gemen t with the local medical schools whereby awdicel students are 
assigned to CHER as assistants. CH£R U able U reeueet the nuaber of 
such students that are to be assigned at a given tlae. Recently, this 
has been limited to one or two students. .Tkf% caJihffjMf,. these ; -S>tude)n*a,.., 
varies greatly; some function alnost as another intern, while others 
tend to get in the way and binder service* 

2.3 Heed for Research 

To fulfill its goal of providing fast, efficient, twenty- four 
hour aedical care, the CHER has to solve a nuaber of problems. The 
first is how to deal with the increased deaand. Currently the CHER sees 
about 100 patients per day. The increasing deaand on CHER in the past 
sixteen years is shown in Figure 2-5. The nuaber of patients has risen 
froa 19,000 per year in 1956 to 30,000 per year in 1970, while the 
population of Cartridge has reaained fairly constant. Such a rapid rate 
of growth necessitates either a physical expansion of the present systea 
or a reorganization in such a way that the present Quality of service 
will not be diainished. 

Constraints on the hospital's aethods of aeeting this growth are 
both physical and monetary. Thus siaply increasing the size of the 
E.R. staff aay not effectively increase its capacity. It is probable 
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Figure 2-5 Changes in Patient Arrival Rate, 1956-1971 
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that through analytic techniques, we can quantify the relationship 
between the nraber of doctors, the nuaber of beds, and the types of 
facilities and procedures to be used. Questions to be answered include 

1. Taking into consideration the different types of 
personnel, the nuaber of each type, and the various shifts, 
what is the optiaal staffing pattern? 

2. How close to operating capacity is the emergency room at 
present? Hew soon will expansion be needed, and what 
resource(s) Kill need to be increased? 

3. Is there a better aethod of allocation of the existing 
resources of the E.R*f 



4. How does the eaergency rooa's preselt role a* an 
aabulatory clinic coincide with its role as an emergency 
rooa? .••-••; 

5. How long aust non- emergent cases wait fl^ tH*#£aent? 
Should a triage officer be used to weed out noe-eaergent 
patients? 

6. What simple changes could streaallne the work of the 
existing doctors and nurses of the E.R. staff? 

7. How will various proposed staffing and physical changes 
affect the efficiency of the systea? 



2.4 Scope of Present Research 

The design, iapleaentation, and use of TIGERS, which comprise 
most of the work reported in this document, actually entailed^researcH 
on several fronts: 

First the systea itself had to be created; the theoretical idea 
of such a tool had to be translated into a working y sab 1* systea that 
could lapleaent dynaaic aodols or T.R. systeas. The prograa that 
evolved is broad in scope, but specific in that 4 1 is actually based on 
Cambridge Hospital. Eaergency rooms are very different froa one 
another: deaands, capacity, staffing, organization, ind facilities -- 
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all can vary with surprisingly great latitude. The techniques 
incorporated by the prograa, however, are general; and TIGERS does 
Illustrate the potential of a more general system. 

Secondly, in order to use the user-oriented system that was 
designed, a test model had to be designed and then implemented as a 
simulation. 

Finally, a third aspect of the research concerned human 
engineering. It was desired that TIGERS be usable by persons not 
necessarily trained in operations research and/or computer science. In 
fact it was desired that TIGERS be a self contained package usable by 
all intelligent (but not especially technical) users, especially medical 
personnel and hospital administrators. Usually such models are designed 
for use only by highly trained technical specialists. It is felt that 
there is significant value in having such a tool be available to the 
non-technical user who knows the problems faced much more intimately 
than does the outside consultant. In order to insure that TIGERS was 
made as useful as possible to those for whom it mattered most, the 
hospital personnel, periodic communication was maintained with people at 
Cambridge Hospital, especially Dr. Peter Hogielnickl . Through this 
communication, valuable feedback was obtained towards making the system 
as useful and usable as possible. 

This report discusses each of these three aspects of research. 
In Chapter III, the idea of modeling is introduced; and the trade-offs 
and pitfalls that must be considered in designing a model of the E.R. 
are discussed. The Hay 1972 study by Harkel et al. is introduced and 
discussed in depth. Chapter IV discusses TIGERS, both as an interactive 
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tool and as a Modeling environment. Chapter V discusses the test model 
that was actually implemented under the TIGERS system. Finally, Chapter 
VI summarizes what TIGERS is and what it is not, and attempts to put the 
program in a realistic perspective. Also Chapter VI speculates about 
the future and points out areas where future research might be fruitful. 
A complete subroutine by subroutine description of the TIGERS system and 
a sample of source code from the program are included as appendices. 
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CHAPTER III: MODELING THE EMERGENCY ROOM 

3.0 Modeling -- Introduction 

In order to apply quantitative Methods to a real, physical 
system, one must create an abstraction, a model, that describes the 
system in terms of aspects of the system relevant to the study. Using 
the model, the analyst can perform experiments which would be difficult 
and/or expensive to carry out on the real system. A well designed model 
can predict how the system will react to changes in its environment. A 
model can be thought of as a "black box" which accepts descriptions of 
the conditions of interest, and outputs information describing how the 
system would behave given this set of conditions. Often, setting up 
these conditions in the real world is impracticable; but the model, 
when it serves its purpose, provides an abstract representation of the 
real world which the analyst can manipulate more easily than he can 
reality. 

Generally, the analyst defines a set of hypothetical conditions 
by assigning values to a set of relevant input parameters, and the model 



describes the system's response by assigning values to relevant output 
variables. For example, we might wish to know how much longer an 
emergency room patient would be expected to wait in a waiting room if 
the demand for service were to double. A model of the system might 
accept as input the demand for service expressed in requests per hour, 
and generate as output the expected waiting time in minutes. The model 
does not, of course, duplicate all aspects of the system; it 
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incorporates only specific aspects in which the analyst is interested. 
The model just Mentioned, for example, would probably shed little 
insight on the question of how denand would change if the service 
facility were moved to another location. 

Often an apparently eoaplex system can be modeled well using a 
model with a well defined analytic solution. A number of classical 
models have evolved which are applicable to whole classes of real world 
situations. An excellent example is the so called "tl/fl/l single server 
queuing model." This model assumes a service system involving a single 
server whose service time is characterized by an exponential probability 
distribution function <pdf). [1] The iutorarrival time of customers 
arriving requesting service is also assumed to be characterised by an 
exponential pdf . If the server is free, the cust om er receives immediate 
service, when the server is busy, arriving customers enter a queue, and 
customers are served in a first come first served manner as the server 
becomes available. 

The solution of such a model yields a set of equations which 
express such useful values as the expected waiting time in the queue and 
expected number of people in the queue in terms of the known or 
pos tula ted parameters, average arrival rate and average service time. 
Often a situation does not exactly fit the model but is close enough 
that significant insight can still be obtained from its use. For 
example, a situation might fit the above quettelag model with the excep 
tion that its service time pdf deviated somewhat from the exponential. 
The predicted waiting time in queue, however, might well still be close 
enough to the true value to be of use to the analyst. It is, of course. 
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extremely gratifying to the analyst when the system under study "fits" 
one of these models with well defined analytic solutions. 

Some real-life situations are not so co-operative and do not 
lend themselves to such models. Frequently, however, models of such 
systems are solvable using computer simulations. The simulation 
technique, which involves dynamically simulating "events" of the real 
world on a digital computer, is generally more expensive, but it can 
often be used to great advantage with systems that are too complex to be 
solved analytically. 

3.1 Modeling the Emergency Room 

©f first priority in any anaayticol prooess is to clarify which 
questions about the system are *f interest. .- JattMh these questions cmjt 
take th* form of "Haw does x vary with yf* sar ; j"Hej* &ms .x. very, with y 
and z and w and ... ?" Formulating thes% question* involve* isolating 
two sets of parameters; a set of outputs (x's) and a se4» of inputs (y's, 
z's, etc.). ■.:-■■ «.. 

In this section we outline our approa^M modeling the 
emergency room. Basic issues are discussed, and an attempt is made to 
communicate the mode of thinking necessitated by the modeling process. 

3.1.1 Isolating Relevant Parameters 

The quality of treatment in the Cambridge Hospital Emergency 
Room — and in many of the nation's emergency rooms — is high. 
Problems in these systems arise primarily when pa|%f ulis cannot avail 
themselves of this treatment because the system is overloaded. Thus as 
a first step in our analysis of the emergency room, it is decided that 
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the quality of medical care per se administered to each patient is not 
at issue in this analysis. Therefore it addresses itself not to the 
problem of inadequate medical technology in the E.R., but rather to the 
fact that requests for service from the E.R. are exceeding its capacity 
to handle then effectively . It is assumed, therefore, that the system 
runs smoothly and delivers adequate service as long as the system is 
operating below "capacity." It is only when demand for service 
increases that queues begin to develop and the system bogs down as it 
becomes "swamped." [2] 

Once it is decided that in the present research medical care per 
se is not at issue, the system can b« viewed as a 1 "service system. " in 
which patients arrive requesting "service" and receive it as facilities 
become available, fife efficiency of such « system oem be quantified 
through such metrics as delays experienced by the patient. Thus the 
following parameters can be considered relevant 4ndtee&<vf : the 
operational effectiveness of an emergency room system: 

1) number of patients in waiting 

room queue 

2) time patient is kept waiting 

before service begins 

3) time a patient actually spends 

in service *-=* 

4) fraction of patient service 

time not usefully spent. 

3.1.2 Obst a cles Inhibiting 

Development of an Analytic Solution 

The emergency room is clearly a service system — patients 

arrive requesting service, are served as servers become available, and 
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are released. But unfortunately it does not fall conveniently into the 
classic queueing model template. The definition of, jshf f fcfy parameter, 
service, is obsoered by the complexities of the system. In a systea 
such as, say. a police patrol force, it if relatively easy to define a 
clear cat server and define a distinct service* timesr^Ibe server is the 
patrol unit, and the service tine is the nuamer ef minutes that elapse 
between the tine a unit is dispatched en a call, and the time it resume* 
patrol or is dispatched to answer another reaues^ for seryl.ce,, fiV 

In th« E.R. , ap obvioe* def init^joa of a*a^c$t JMfllW M?4£aw>- ?n$n\fc 
in treatment. But what defines treatment? i)ftat4fc.$|a. aaryarJU **■ th&< : : 
police patrol example, the farver, is,. c^af^lj^aatfel^Mn^^ In the -^ 
E.R?. example one is at first teapted, to de/loti tta&R^fcmjl as !*J»Ph r . w iiUS - 
server . But this is clearly inadequate; t no^fejry^cejif bel^g rendered. 
when a patient is lying in a bed* waiting ,f|»r s %dec^»r to become 
available . llie analyst Is then taeoted to deald* thai the, djactor* ,^s the* 
server, but this is equally unsatisfactory v ^^MMi#n%o^iiMI ^he x-i?^ay 
facility is unquestionably receiving tree^aent* but if M»e 4p^tQf\ were 
defined as the server, the pat iaflt at x-^^y, *««Wb«cl^ ..,*,* ; - 

receiving no service. -,,-.. ;- ^ ; .-rr^ 

Thus the analyst of the hospital M/mm/mm room is quickly 
confronted with the problea that there ape sewe^il f|a(pe*#f ; treatawnt rin 
the E.R., all of which consti^ut«"s«ryic»e, 4 ^ $er^e&xan tat*. th* forms 
of treatment by trained personal ■■mafymmm pf physical facilities. 
( Personnel does mot lomly mean doctors , however * Jostles important are 3 4 
the nurses and paramedical persons.) 
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Not to be overlooked is the proble* of hew to deal with •blocked 
tine." A patient is Said to be "blocked" when he is welting for « 
resource (e.g. doctor, narse, lab report), but not reciivifia eny other 
type of service. Large aattbnts of blocked tisw indicate that aere of 
that resource is needed in order to be ©rwretioeally compatible with the 
rest of the system. For exaemte, e large neaber of beds would be 
worthless if, even though every patient revesting service were 
iaauidiately assigned a bed, he spent e^tbf-Ms'iii^in^d "doctor 
blocked* state^ welting for a doctor. In such • systea> a wasteful 
imbalance would be present: if the deaaitf were large, mere doctors 
would be needed; or if the demand werr not' so great ; -the* expense has 
been wasted on *xtra bed*. In any cl.ssical serving/ '%y%^Hbs«M^*t i* 
assumed tbet using *hd resource that i* the server {or part Of it) 
constitutes service. Hi the emergency room, howeve r, t* 4s possible to 
havb a patient who ie really receiving no servlcV • w cep t in that ha -' 4s« 
consulting one -of the resources. h ' :n ' 

Another classic Okampte Of blocked tin* is the patient who bats 
been treated and f» e*5«nti«lly re*dy tafbe releaswl^roa»Xhe X.R. , but 
who, for one reason or another, is still occupying a bVd^i^Buclic 
situation might occur, for example, in the case of an aged person who 
cannot leave unaceoa«tan led, but whose cesma^^ 
take responsbf lity for *imv Another instance ygf this *extt> blocked" 
state often occurs for E.R. patients who are finished *itti all E.R. treat 
sent and a¥e to be admitted to the hospital. Adalsslon to /the? hospital 
Involves a considerable aaount of adainistra^ivo ovoihaad , and it Is not 
uncommon for the patient to spend considerable periods of tine waiting 
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for this processing. 

As one gets deeper into the analysis or the emergency room, such 
basic questions as when a patient is being served and how much service 
he is receiving become significant. In the standard servicer system 
models, the only variation in service received by various customers is 
in length of time of service. Patients i« the emergency room receive 
not only different lengths of service but also highly varying types of 
service. A patient In a blocked state waiting for a doctor is only 
receiving service in that he has a bed. At the other extreme is a 
cardiac arrest patient who may be receiving aery ic« from numerous 
f aciilt ies (defibrillator , monitoring? equipment ,z Mm Jfcs am* personnel ?-r 
(continuous service from several doctors and amrsaajv- Between the two 
extremes are a range of situations difficult to c&essify. 

One example is patient observation. - ^meMmoa it is necessary 
for a patient simply to wait in a bed for an "observation period. • A 
patient with a drug overdose, for example; will stay for a few hours to 
make sure that there arm jio more complications. During this time, a 
doctor or nurso will see him a few times^Mt f oruShtt; imps t part Hho-<^uatf 
waits until the doctors are satisfied that he is well enough to be 
released. A person under observation uses up a. bed, but how much 
personnel time does he use?: What service is he receiving? Such 
questions have no well defined answers. 

Similar questions can be asked about such situations as those i» 
which laboratory analyses are ordered for the £.&. patient, tte patient 
awaiting a lab report may be receiving no treatment except in that he is 
occupying a bed, and yet somewhere in the hospital his blood sample is 
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being analyzed. How do we classify this type of treatpent? Where doe* 
it fit into a Model? Again, such questions have no-well defined 
answers; 

A significant part of any analysis is to gather data f roM the 
systea being analyze* upon which to base paraaeter values of the Model. 
A value for average. service 4iae, for ejowiple* needs to beidetonainedi. 
In the E.R. this can pose a, serious pr ob lew. It has already been itoted 
that patients receive* vary log; degrees aad: type* of service^ A patient 
■lght require ten alnwtes «f nurse tie** f l*e aiaertes of x~ray tia>e, 
thirty seconds of doctor tiao ,;- and thirty Mtautit^ of ■e*a^4iam -. - ■ Another 
Might weed twenty ainutes *f nurse ti*» , twenty BUMta* oft doctor tie* , 
ten Minutes of lob tiMOv «*d "two ¥mtmmntm&mUm+nlkl& r TmriMi&mn: ■ 
poses only a Minor praMeM to the data gatherer, *lie»iaori©es* probloM lav 
that • the service* areajb*^^llvwee> ■tn?eje*r mm Measure packages . 
Return ihg once wore *o the police patrol inwupl a*, eaieiuwtus that data 
gathering iar a rather straight f iuwerd processv < > aarwicav can; .bat. awabarod ■ 
in patrol unit ttintftes. There 1« nojfanalogoas?«wntai ofHsarvAfiO? f or tha 
BMUrge ncy ;rw»aw e ffURSbbnsore^ whoewar i« using m >a«rvafti 4' potftoi -un i*& - 
has the entire server dedicated to Its*^ is 

dispatched to answer the call, and ends whew *ha wait i i awi— is patrol «c 
begins service on another call. 9.aervac«£sb/ tlne&lerf 1* ganefutlly not at; 
all dedicated. The euergency rooa 1* e> coaaaawt ay ahongin g scen» Wi?th ■■- . 
doctors and nurses* c^tiiwwrtly ae^ing frew pot lent tftaajtlofft* tfolrty 
seconds here, two wiwutos th e ro .i < Hooiiur lag B arvioe anaooivad by each 
patient becoMes a forw idab le problwa. 
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The problem is made even mere complicated by service being 
rendered by non-E.R. personnel and facilities. The E.R. is not a closed 
system. It is common practice to have a doctor caMed from the floor in 
order to consult with one of the E.R. doctors. The most frequent 
occurrences of this type occur when a surgeon or an orthopedic 
specialist or a psychiatrist is needed. Also, in the case of patients 
to be admitted, a doctor from the floor is called to initiate and 
supervise preliminary medical care (care administered before the patient 
is actually officially admitted by an admitting officer). These 
"outside doctors" use the E.R. facilities, including one of the beds for- 
the patient, for what are sometimes large periods of time. Several non- 
E.R. facilities may be involved in the care of an E.R. patient. The 
most common of these are the x-ray facilities and the laboratory (used 
for cultures, blood analysis, etc.). Specimens obtained in the E.R. are 
taken to the third floor laboratory by a nurse or nurse's aide. (Note: 
Host patients walk to x-ray, but if one of the beds of the general 
treatment room is needed for transporting the patient to x-ray, its 
space is left empty. Another bed is not moved in.) 

The reader may note that underlying this entire discussion of 
the complexities of tile emergency room has been the idea of *otance. 
Smooth and efficient operation of tfew emergency .?iieem»is absolutely 
dependent upon a proper balance existing among tfc* available resources. 
There is no single server in the emergency room. 8ed$ ai*« useless 
without personnel, and personnel are «seiess without a place to work. 
Carrying this idea one level further, doctors can do little unless there 
are also enough nurses in the system, and nurses, in turn, are only 
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useful if there are enough doctors. The marginal utility of an 
additional unit of any resource is highly dependent: upon ther existing 
quantities of other resources. 

3.2 The Hay 1972 Study 

In Hay, 1972, one of the first efforts in emergency room 



analysis was undertaken by Harkel, Purks, Shields, and Weissberg. [3] 
Their purpose was to gain insight into the interrelationships between 
number of beds, staffing patterns, and arrival rate of patients; and how 
these parameters affected the quality of service as Measured by the 
indices defined in Section 3.1. The study was one of the first attempts 
at quantifying these relationships. 

In som ways, the TIGERS nodel is an extension of the work of 
this Hay 1972 study. In this section, we therefore discuss this study 
in considerable detail. In the last section we nade an attempt to 
communicate the type of thinking necessary for Modeling the E.R. This 
section, in addition to describing the work of the Hay 1972 study, is 
also an extension of that attempt. 

3.2.1 Simplifying Assume* ions 

It was decided marly in the analysis that toe emergency room 
could oe viewed as a multi-server "service system 1 as described in 
Section 3.1. Once it was decided which p a ra m e ters wire relevant *• *l*m 
analysis (and of Section 3.1) it was necessary to memo ^number of 
simplifying assumption*. This is necessary for any modeling process; 
factors which do not significantly affect the •arameters. of priste 
concern can only add overhead. 
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It was decided not to include pre-emptive emergencies in the 
model, because the vast majority of the CHER'S patients are non- 
emergent, and it is this type of patient tiwt is eventually going to 
strain the capacity of the system. Furthermore, although an emergency 
such as cardiac arrest requiring the entire emergency room staff for an 
hour or more seriously disrupts the system, ■&> happens so rarely «that 
the facilities of the shock room are thought by the Jtospital to be 
adequate to fill present needs. (The bed jwith ttie defibrillator, 
etc. is at this time used only for pre-emptive emergencies, net for nen» 
emergent patients.) 

Another assumption involved peripheral facilities: the use of 
the psychiatric, pediatric, gynecological, and alcoholic detoxification 
facilities and staff usually does not involve members of the E.R. staff; 
and the facilities used by these departments are independent, for the 
most part, of the general medical treatment room. For this reason the 
mathematical model did not include these facets of the E.R. 

The physical capacity of CHER is about seven patients in the 
general treatment room. There are five beds in this room, and new 
patients are seldom called in unless there is a bed free. However, 
there are also a few chairs; and many patients, not in need of a bed or 
Who come back from x-ray and find no beds available, sit in chairs. 
From the physical size and layout of the room and from their own 
observations, the team determined that seven was a reasonable estimate 
of the maximum number of adult patients in the system at one time. (The 
nurses almost never let more than seven in the room at one time. If 
there are many people at x-ray, then even if beds are free, no more 
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people are called in; thus the roan is prevented f rat becoming "flooded 11 
when those at x-ray return.) 

Because the rate of arrivals a* night was low. It was decided 
that it would be inefficient to Increase the night staffing above the - 
present one Intern policy. If toe aany people to be handled by one 
person arrive, the intern can oa*l elset*)cr*riN£i*4n ffehes. hospital f or 
help. Thus, the ftsrkol etal. aedel cancaacr^ 
. . • with an arrival nrt» of five people «pe^ book <*e^ 
and one staff doctor on duty. ■■■ 



3.2.2 The Two Stage Itodel 

The sain object to be node led was the general treatment roosi. 
Typically a patient is called in by a nurse, who assigns bin a bed and 
takes his vital signs (pulse, teaperatere, etc.) before he is exaained 
by a doctor. Mi lie a patient is in the eaergency roesi, he is seen aany 
tiaes by a doctor, usually for periods of a aiaute or two, rather than 
for one uninterrupted period. In addition to the eaergency room doctor, 
the patient also receives a noaber of non-eaergency rooa doctor 
services, such as laboratory tests, x-rays, consulting physicians, 
nursing, and resting and waiting. These "non-doctor" services overlap 
each other and overlap the doctor tine also (e.g. a nurse often helps a 
doctor treat a patient). To be absolutely true to life, doctor tiae 
should be Modeled as the sua of a random noaber of randoa variables 
interspersed with a randoa nuaber of randoa- length non-doctor services. 

The approach that the team took towards fitting the eaergency 
rooa to a aodel with an analytic solution was to divide the tiae a 
patient spends in the eaergency rooa into two categories: "doctor" and 
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"non-doctor" tine. That is, a patient in the emerg*i*Jr»rh*i receives 
two services, those of a doctor and those of all other facilities and 
personnel. An inherent important assomptlen, indeed a tey aesemptiotf of 
their model, is that all noh*docter tin* ah*. ill doctor time are 
aggregated into two uninterrupted service 3 per ioids.*' 

All patients are assumed to avail themselves of non-doctor 
service* first; This includes rwrsirrg, being seen gfr* noK efc rtr f onc y-room 
doctors oh a consulting basis, getting^ » blootf tes% or" *iray, " or b«ilig^ 
urtder^ ob*erv»*lonV Hext. 1* *li*mede*e*l pet tents af^^een by * doctc* 
for an uninterrupted period of time . When Mfc^dccto r fenc^on* overlap 
doctor functions (e.g. being seen by both It t* **««•*< «Mf» # hereof ?e*e v tM» ; 
is 4 counted as being *eoctor time. 1 * /;,;-•' '''^ v '" 

Because there ar» at mos% threif ^eguler* de%%er» in the -em«rge*cy1 
room at one time, and one of these is the staff doctor whose^ihbTh ?' is ? * w 
theoretically is as a consultant for %h* «rtiero*, 'tM^humtth^ of people 
being treated at any on© -tineas Usually ^ei*M-thaW^#en^-' ^fle^'ttiore ''' 
are seven *bed*,* only three of then oW.lkmi&i%#< : mWSt4* i &t {Hifcov 
The Others , if they have finished their » o n doc tor service ^*^thwr? 
medical tree taent being administered), aVV^frnttttie^^ W*l»4e^^..--' 
"blde1ted'*- state, i.e, waiting for e idee tor;-' 

Since the te«* decided og# conoerttrate their analysis only on the 
physical capacity and the number of doctors mf «hi CHER, -«tb*ir model 
does not explicitly account for nurse**! mod ice 1 students , paramedical 
students, orderlies, etc. They are, ho we ve r, in eerpore ted fwto^tfle hen^ 
doctor time of a patient. -'••"*■>-■ - -w- 
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3.2.3 hodel Structure 

The teaev's nodal of the enwrgency roon is shewn in Figure 3-1. 
Seven patients can b« treated *t g^ tin*, and each patUnt receives two 
basic type* of service, "doctor" and "noo-doctor .*i s \Q4$* *a van, patients 
can be in the systea at any tine, only , three, or ,f*war (assuming £here. 
are three doctor* en duty) will ^-ji§U9^i^4§§$9f^^.mf-'9^ M*«- T* 16 
remaining petiaots wiU either ba recaivijia cere other than from an 
emergency room doctor or. will be blocked, waitinf |jof*aj4oc^o|- to «an>.. : .; 
them. - Tbu*, the modal 1* * **» i&^miWfffWNft^ta^p^m-W***-.: 
allowed between the two atego*. If x doctor* are bosy with patients, .. 
then 7-x beds ara available for other patients, both, for nonndpsitor 
services and for waiting to see a doctor >, ffi ^ queu e *s #WM» W *A *Q form iA 
front of the first stao# of the nodels tb*# aueup corras&wd* J*> the 
waiting room. ;i ,, •>*•• ^ -^^dj k. :•.•■-.■ *m* ^.s-iJ ::■■-,-- *•- .. 

• Service tinea are assumed to be exponential. £*% t din^bn^on. 
of doctor, and non-doctor tine* ©f a; 400* aamp**, .jfcfMM *K •leven hours 
of observation on each of «*» day*. fta, l ajwjp^*fj|annm, 3-3,, a Jh* 
distributions support the e xpon e n tial se rvi ce tiniaaesonirt iqns . The, 
mean doctor tiae is tbo parameter I/», and th sjim tan aon-rioatw -tine ^4a> h« 
the parameter 1/0. For the fine* n*de2«f the oteaent sy»*ea r it was 
assumed that two : &&r&m*4M-**IBhijlnifamKMjmj6&»ifr «*Jht-~ 
enwrgency room end that the staff eec tor foUewed hi* theqreUcal role, 
action as a consultant to the ia*«r»». It m» «l»o^»at»wl. however, 
that when the system we* full Isaveji patient*), tfca «%*J|f *#*M»r woi44 : 
deliver priaary care. Because the staff doctor was, jao£ is "eaya^abl«> ;*|or ; 
help or consultation while he was a priaary server, it was assumed that 
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the average tine needed to care for a patient increased; was used 
instead of 

The arrivals to the systea by hour of the day for a one week 
100% sample are shown in Figure 3-2. The arrival fate can approximately 
be represented by a Poisson process with an adult arrival rate lambda 
which varies from 1.2 people per hour late at night to AM people per 
hour during the day. The model has seventy-six states, each 
characterized by the number of patients being treated by facilities or 
Staff other than an E.R. doctor, the number being treated by an E.R. 
doctor, the number "blocked," and the number in the queue. Length of 
the waiting room queue was limited to five in order to keep the number 
~vf states of the system model from becoming unreasonably large. Also, 
observations indicated that very seldom! ware there more than five people 
%n the waiting room at any one time. 

The preliminary work of Harkel it al. provided evidence that the 
two stage queueing model can be useful. There was, however, a. consensus 

i ,»•« <'" ! ■""; ■ f^ 5 

that a computer simulation would probably yield stronger results. First 
a simulation would be much more flexible -- quantities of resources 
could be easily manipulated. Second, since no analytic solution would 
be needed, fewer simplifying assumptions would be necessary. 
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CHAPTER IV: TlSERS 



40 I ?^f?^f t M 

_. An mentioned in .Chapter I , ^ the jgr a^M^rjygaj^ was^, mp^ya£ed,by ■ 
the goal of cree^ng^a^^ 

hospital admifM^ftor, and .which* could aid ^ *r4dgia* the 
comewnicatioos gee the t exist* between the^dp*eUtrator and the 
analyst. The design and imp l a eoaU tloa of tbor progcs* /TIGERS represents 
the greater par*, of t the work of tbi% f^aaere^#roject .» A direct 
outgrowth of the gerkei et #1. st*dy, the ?M**S system wes developed 
with two mein goals in Bind: 1) to design and i ep te pe e t * simulation- if;Tr , 

based modeling environment which would necessitate fewer simplifying 

noiisLanitZ Igs-tdceiw .,■■>• r„/- <« J r;l i. . . 
assumptions than the model developed by flariel, Purks, Shields, and 

- ~-:-\ ;■-:■■ • i-^i \ •■. .;-3^' -j n ,•--„?- 5t3*i >i jaa&soTivjj!* Jj-B^t -ft 
Weissberg; and thus make possible a mere detailed and policy-relevant 

model; 2) to develop a medium of communication for presenting the 

quantitative results of the analysis in an intuitive manner requiring 

-•-/■' ■■!' . ■.. '-^njiixs *io*i - :j.ie.'i a"iuj«1 elubarise levies <iS2/vi st^:'- :•■.-■■*,'<■•/ 
little training in systems analysis to comprehend. Pursuant to the 

goals outlined in Chapter I, the primary research effort was 

■ - ■ ~ . 4 * ',:■ -i .T -;: ;i -■» ..; ^o ■- •;. ~n - 'to Jr.sWD ■?&$ zinsmsTS^b 5i *^r-2i-,- . .- .;-..:: 
concentrated not on designing a highly accurate model of a particular 
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emergency room, but rather on development of a tool which could be used 



for such a purpose. 



j^r;'. 
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Any analysis of a public system is almost necessarily a co- 
operative effort shared by the analyst and the public administrator, if 
the project is actually to result in constructive change of the system. 

" , 13001 J jiSSiw fid'" til/ail 

The analyst has effective mathematical tools and skills, but it is the 
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administrator who has intimate familiarity with the problem at hand and 
who can keep the analysis on a track where it can be of other than 
academic value. 

In this chapter, the Tool for Interactive Graphical Emeroency 
Room Simulation is discussed in detail, as the environment it described 
both fro* the 'molar of view of ttie trtrS pi tti administrator and that of 
the analyst. We first define the typw off simulation Upon which TIGERS 
is based. We then introduce the idee of* ipjmpli«cal *ate*«cti«A and the 
modeling philosophy which makes the TWHSS model somewhat different fr^oof 
other simulation models. me*t *b* user viewport and interaction with 
the modal are introduced, and finally the idem «f TIGERS as a modeling 
environment is dicussad. • t .-«i&-:;j *Jao« ;<:.»* 

4.1 Interactive Graphical Simulation 

The TIGERS environment is based upon a so-called e»e*t paced 
simulation, in which the model has associated with it certain data 

. -.,/ :.".•■•■, '."'*' T'.;.; ■-'■": ' : '- ~ ; :- •t > <;.- ; "?.«•■• f :fc.< "-■'•fit v"' ■■ : •• 

bases, and the simulation executes a sequence of events which may change 

■'.- ,. " ilv'Oi. '"< '■'-■■ ' -:•"■ S'»'i* ; v- ;''?... .pr ill >. ' -i'O bilk S»U IO ciJ.iCi£^*5 Svi*: ..;;./'!*>'■■■ 

these data bases and/or schedule future events. For example, the model 
might incorporate the event "send patient to x-ray." This event changes 
two data bases : it decrements the count of number of people in the main 
treatment room, and increments the count of the number of people at x- 



ray. It may append the patient to a queue of patients waiting for the 
x-ray; or if no one is currently using the x-ray and no queue exists, 
the "send patient to x-ray* event will determine how long the patient 
will be at x-ray, and generate another event, "return from x-ray to the 
main treatment room." 



*5 

In a typical computer simulation envirotm«At f tbo usq af a 
simulation program involves three steps: 1) A set of paraaeter values is 
determined. 2) Ute siaulatioa is rwt for a pi;e«et length of time or 
number of events, or until some prf set condition is met. 3) The printed 
output of the values ef variables deemd iae9f?t*at is examined. These 
three ^teps may be rapeated a nimu>er of itimes« Allrimformatien 
communicated to the user from the program is transmitted through the 
"printout." ;j 

The Bhil«»ephy of the TIGERS program differs from that of most 
othor simulation programs. A simulation under TJGESW is an imtera^t^ve 
graphical process, i.e. a process which •atfltains coatiauous two-way 
communication between the user and the program; eiaej simulation 
communicates with the user, not through computer printout, hut through a 
dynamic graphical display en allfwacepe.d-P^rougti this medium, TIGERS 
keeps the user continually informed of the prison* state of the : 
simulation. As be 4a monitoring the^pf^rrmssi of tthev simulation « the 
user has the ability at any tine to start or stop the eiswlatlon or make 
parameter changes or request information. Its interactive graphical 
nature facilitates use by the doctor m pmblic admiedstrater as well as 
by the trained analyst. More accurately, one etfmht amy that such a 
system is accessible by both, and therefore can hopefully serve as a 
focus towards creating a mere effective tmanu^a Jn^ the mext, sections we 
shall discuss in greater detail the ramifications of these? graphical and 
interactive aspects of the program. 
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4.1.2 User Interaction with Simulation Programs 

The key feature introduced by a high degree of interaction is 
great flexibility, since flexibility (as we steal! discuss below) is 
largely a function of degree of interaction. Flexibility is desirable 
because it encourages toe extraction* of «J large euaatity of information 
from the program in a relatively short uttm. «Oegre« of interact ion can 
be broken down into three categories. 

The "lowest" category is 1*at of a so-called "batch programming" 
system. In order to execute one run of a simulatioi*; the user decides 
upon a set of parameters, types then Up {usually off punched cards), and 
submits his deck (typed prograa) in an input bin. Hours or days later 
the user can pick up his deck and printed output from his output bin. 
If the user wants to try out another idea, he must go through the same 
process again. 

The next category of interaction is that of standard time- 
sharing. It is significantly better in that the user communicates with 
the program not through punched cards, but through an on-line 
teletypwriter. The user submits his job from his console, and the 
computer types the relevant results of the simulation on the user's 
console in minutes. This is, of course, a significant improvement over 
batch processing. 

A third category of interaction is interactive not only in that 
the user can change parameters before running each version of the 
simulation, but also in that he can interact with the simulation at any 
time during its execution. Such interaction was strived for in 
designing the TIGERS program. The graphical trace allows the user to 
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follow the simulation as it runs, and as long as it looks interesting, 
he can let it continue to run. If he sees an interesting state, he can 
temporarily stop execution end investigate the state in depth. If he 
wishes to change a parameter at any tieeditring the simulation, he is 
free to do so. Thus simulation in a TI6€*S-lifce environment becomes a 
process which the user can continuously observe and rim which he can 
participate. Such a program is not bound to the three steps (Ascribed 
earlier which characterize most other simulations; the graphical trace 
creates, a situation such that tht program cee he -.rum fmr as long, but 
onJLy as long, as the user deems It useful. 

4.2 Interaction With the Simulation 

Implementing an E.R. model under TIGERS necessitates interaction 
with the program at more than one level . There is no rigorous 
hierarchy, but if forced to differentiate, one might isolate two primary 
facets of the use of TIGERS. On one level, the program is an 
interactive graphical simulation with which the user can experiment with 
a given model through use of the program's two operating modes. On 
another level TIGERS is a modeling ■environment where subroutines are 
written and data bases are structurally modified, or sometimes even 
newly created. 

In this section we discuss in detail the use of the interactive 
program to experiment with a given model. We will refer to the 
experimenter as the user of the program. We describe below the man- 
machine interface and the use of TIGERS at the "user level." 



69 

4.2.1 Physical Facilities 

The program TIGERS communicates with the user primarily through 
the graphical display oh the CRT scope. The user, in turn, can give 
commands to TIGERS through the hand -he Id stylus (pen) and tablet. 
(There is also two-way communication through the teletypewriter, but it 
is generally unnecessary at the user level.) The facility is shown in 
Figure 4-1. The user sits in front of the CRT with the tablet 
horizontal directly in front of him. The pen and tablet allow the user 
to "point" to objects displayed on the CRT. The tablet is a surface 
that is sensitive to the position of the stylus. The surface of the 
tablet maps into the face of the scope seeh that touching a point on the 
tablet with the pen is like touching the corresponding point on the 
scope. In this discission when we refer to taject on the 

display, what is actually meant is touching the corresponding point on 
the tablet. (In actual u: the user'owtckly forgets that he is really 
touching the tablet : Because the pen |fQf tt 1 fl^tljitofy i, t rt 1 1 p I a j o rl on 
the scope, the user feels as if he WAfv^^p|^^^fcre«n ,) 

While the program is running, the user can e* amy time point to or touch 
displayed objects. 

Certain objects called Mspl ay buttons are sensitive to being 
touched by the pell* and it is through the display buttons that the user 
can give commands to end otherwise communicate with TIGERS. In TIGERS, 
all light buttons take the form of a label and an associated sensitized 
area in by a square. For example, the button to command 

initialization of the data bases before an execution of the simulation 
looks like this: 
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n INITIALIZE 

Whenever the square is "hit" (touched) by the pen, the states of all the 
resources are reinitialised. (A more detailed description can be found 
at the end of Section 4.2.2.) 

TIGERS operates in two possible "aodes," Modify and Simulate. 
Simulate is the mode in which actual simulations take place, and Hodify 
is the mode in which the user can change the values of various 
parameters. When TIGERS is first started, the program is in Simulate 
Node in a "stopped" state; i.e. the simulation is stopped, but ready to 
be started. TIGERS is inactive but listening, waiting for a command 
(i.e. for a button to be hit). The CRT Jm an initialized Simulate mode 
appears as in Figure 4-2. This is the stage upon which the scenario of 
the simulation takes place. 

4.2.2 Simulate Node 

TIGERS' stage is composed of thictaeastpar ate sectors: Main, 
Blocked, Waiting, Lab, X-ray, Shock, E.R. Staff, On Call, Lounge, 
Nurses., and three unlabeled sections. (Blocked, Shock, and Lounge are 
not used in the current implementation.)" Each sector represents a 
different subsystem of the emergency room. The mobile elements of the 
system are the stick figures with various shaped heads (see Figure 4-7) 
which represent the patients and the emergency room personnel. For lack 
of better identifiers, nurses have triangular heads; doctors, hexagonal; 
consultants, octagonal; and patients, square heads. Numbers and types 
of persons in each sector are indicated by the presence of the 
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Figure 4-2 The CRT in Simulate Mode Just After Initialization 
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appropriate number of the appropriate symbol (stick figure) in the 

sector. The clock at the bottom of the screen indicates the elapsed 

simulated time since the last START of the simulation. . ^ 

Three of the sectors are indicators of available emergency room 

personnel: 

Nurses — emergency room nurses :^ ^ 

E.R. Staff — doctors (including imtermsf assigned 
full time to the emergency room 

On Call — doctors who, although not stationed in 
the E.R., can be called into the E.R. when 
it b e co m e s crowded . * 

These three sectors indicate number of staff who are on duty and not 

busy, i.e. ready to treat patients. Thus when the program is 

initialized, these sectors indicate the total number on duty, since at 

time zero none of the staff members are busy. Thus the parameters of 

the model of Figure 4-2 are initialized at four nurses, three doctors, 

and one doctor on call. 

When the simulation is initialized, no patients are indicated in 
any of the sectors, because patient arrivals do not begin, of course, 
until the simulation has started. 

The sector marked "Waiting" represents the waiting room. As 
the simulation generates arrivals, they are assigned to a bed if 
possible. If this cannot be done (e.g. if no bed is free, or all nurses 
are busy), the patient joins a queue in the waiting room. 

The area labeled HAIN at the top of the screen represents the 
main treatment room. The bed-like objects represent beds. Associated 
with each bed are four "fields" (Figure 4-3). Field 1 is the patient 
location field (Figure 4-4). It indicates that either the bed is not in 
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use, the patient is in the bed, or the patient is at x-ray. Field 2 is 

a patient state indicator field (Figaro 4-5), It pay indicate the 

following states: 

OBSERVE*-- under observation. Often a patient will stay in 
an E.R. bed, soatetiaes for several hours, siaply to 
ascertain that he is ready to be released. Patients with 
drug overdoses, for example, are often watched for a while 
before they leave the E.R. -.-,.• y; :ma ry,< ■■■■»■■■ 

LAB WAIT — lab blocked, waiting for Ub test result. 
Often, a patient's treatment ,4a delays until his test 
results are back fron> the lab. 

EXIT WAIT — exit block«d, finished with treatawmt, but exit 
delayed. Delay sight be caused by adninistraUva red tape, 
or soaetiaes siaply by lack of transportation. 



These states are critical because patients in these states account for 
anich of the use of a significant E.R. resource — bed space. 

Field 3 is a "server indicator" field (Figure 4-6). It aay 
indicate either that a patient is being served by one of the E.R. 
personnel or a consultant froa> the floor, or that the patient is in a 
"blocked state" — receiving no treatment and waiting for such service. 

Field 4 specifies the "type" of patient occupying the bed 
(Figure 4-6). Patients aay be classified by type of treatment 
necessary; and by Monitoring the types of patients in the sain treatment 
room, the user can ascertain which types sake the greatest resource 
deaands of the systea. 

*In a typical "scene" there sight be a couple of patients in beds 
being seen by doctors, a queue of patients waiting for the x-ray, and 
several available E.R. personnel. A change of state (e.g. a patient 
Braving from bed to x-ray) is displayed as it occurs. The user is able, 
for example, to see a patient sent to x-ray, see queues build, or notice 



75 




1BSEPVED 



FIELD 1 



FIELD 4 



FIELD 2 



O 




FIELD 3 



Figure 4-3 Four Fields of TIGERS Bed 



-.sy* - : : -; -^:*3#*®^^ 



76 



FREE 




RT X-PRY 



Figure 4-4 Betl Field M Threr' Possible States 




LHB WHIT 




but yflit 



dfl^EPVEbl 



Figure 4-$ B«t Fiekt •-?? i HtoP f&wbfa State* 



77 



HMIMMBilVMi 









"' " 


- 


•« 


/^S 




1? :."#,.: 



W5E her trr ax dj?blk 






Fi^yre 4-6 Bed ftiel«\3; a»d &&4.Ei^d>A: 
Seven and Three Possible States, Respectively 



^W^WSiWJ^&?5Sfef ifr- •■ 



78 

a patient in a blocked state waiting to see a doctor. 

Figure 4-7 is a typical scene which sight appear on the CRT 
during a TIGERS simulation. In the out in treatment rooa we note seven 
beds. There are seven patients in this scene, six of which are actually 
present in the sain treataent reea. The seventh is in the x^ ray area. 
Note that two patient* are waiting for laboratory analysis results. The 

'"■'l : ' ■■ s ' ■' ■''' '"< " ' "* '* ^- « L ~ : •£ ' '" ~ 

eaergency rooa represented by this aodel is sta f fed by "three thnrtors an* 
two nurses, and has one doctor on call. n|%itlie|nejr»f»|iir|»!.f^sy (hence 
the patient in the nurse blocked state). One ef the doctors is busy and 
the doctor on call is available. One patient is under observation. 

An important aspect of the display is that it is intended to 
lend intuitive "feel" for what is happening as well as convey 
quantitative information. It is for this reason that queues of patients 
or staff are represented not as numerals, but as actual collections of 
stick figures . A crowd gathered in the waiting room conveys a audi aore 
intuitive idea of the property "crowded" than dees the nuaeral "11." 
Siailarly a blank space in the x-ray area conveys the ideas "empty" and 
■not crowded." 

It aight be argued that the nuaeral "0" coaaunicates as well as 
the blank space, and that the nuaeral "11" does as well as eleven little 
figures. The author contends that this arguaent aight be valid if one 
were only interested in the state of one data base, say, the waiting 
rooa. But when one is interested in the state of the whole systea, the 
stick figures communicate: much mora effectively i tfeiff numerals instead 
of queues of figures adds one level of abstraction. If one were only 
watching one queue, this abstraction aight be insignificant; but when 
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several data bases are being observed, the extra level does becoae 
significant. 

The two unlabeled sectors in the low«r right corner of the 
screen contain the light buttons which correspond 8 tajjjNba fix I iiaaj|hds 
which TIGERS will accept in Siwlat^%de."*<%e#%re as follows: 

START — starts the siaulation. 

STOP — stops the siaulation, if it is running. 

CONTINUE — allows the user to continue ^siBiHating from 
the point at which hef STOPped execution. ! 

I i 

INITIALIZE — reinitializes all data bases to fj**^' r 
initial state. Waiting room, lab, and x-ray are eeqftied; 
all beds are aade frekv all staff are aade available. 



STATISTICS r- really two &ttf|#M ON displays in the 
unlabeled sectorj at the bottoa of Che | screen cuaulative 
statistics such as total nuaber of patients that have* gone 
through the systiuy^pampnje waiting tin* and average) service 
time. OFF erase* -the display of statistics. (See Section 
5.3.) .1 % I t 

MODIFY — sjtops the siaulation aid switches to JHodify 
;;- iT - r : Node. ; -.;..» :r j r ijm® 

.....,.....;' . .. .. ... .„. _ J,. ._„._.„..,..,. .-.-J 

4.2.3 Nojjlfil Nf de — Changing Parameters 

possible for the user to alter critical parameters of the 
sijRtatiancilb: any tiaw that the siaulation is stopped. A^l changes are 
■ade in Hod&fy Ndde, and switching to Modify Node autoaatically stops 

■v*r: \ «s« ' fiWiT:'^- 

the siauletien . In the present inplenentst ion of- TWERfrrnpon entry to 



Modify node the display appears as in Figure 4-S. The eight paraaeters 
in the upper left are the siaulation paraaeters which the user can 
aodify. It is a trivial operation to add or subtract froa this set of 
paraaeters, but in the present iapleaentation, there is no way for the 
untrained user to do this autoaatically. Altering the set of 
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"adjustable paraaaters" 1$ at this point a Job which involves 
programing, albeit a staple one. 

The lower half of the screen in Ifodify aode is known as the 
"blackboard." It consists of a "writing area,* tea display buttons 
associated with the ten digits, a declael point^button, and an erase 

$?% '■ „ -& i *->*■ Jt-?®"» ^;-;i-»A '■■-■■■->.; --., ::-,, ...... 

button. The blackboard is used for emetliM tnjff -ifri^f^jfoich «r p in 
turn used to assign new valuea #t#adel p«mu|af **T 'J**,, ""cjurnant text 
string," which upon entry to Ifodify aode is the null string (no 
characters), is displayed in the writing area, whenever any of the 
digit buttons or the deciaal point button is hit with the pen, the 
associated character is concatenated to the and ef the current string. 
In this aanner, integral or nonintegral nuabers can be "written" on the 
blackboard. The erase button is used to reset the current string to the 
null string in case the user wishes for sou* reason to rewrite the 
string. 

When the user wishes to change the value of a parameter, he 
touches the associated button. The program responds by displaying 
"CHOOSE NEW VALUE."" Th§ user than writes a auablr, the Hew value, on 

' . '■'■■ , T - ; ■■'"■'? t'^ **■■* ■*—: ¥~ 

the blackboard. This done, he hits the parameter button again, and the 
value of the parameter is changed, both on the screen and in the 
prbgraa . Figure 4-9 is a snapshot of the~Otf in Modify Node ^s the 
blackboard is being used. The user is Modifying the x-ray tiae 
paraaeter for Type 3 patients. He has already hit the paraaeter button 
and is now building the text string representing the new value. The pan 
is still on the "zero" button which appended the last "0" to the text 
string. The user's next step will be to hit the paraaeter button again. 
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whereupon the average x-ray tine of Type 3 patients will be changed to 
20.0. The interested reader will f ind e «ore detailed description of 
Modify Node in Section A. 13. 

After he has Modified all the parameter be wishes to 
change, the user can return to siewlate e»ae by Jf thfc^KMRJI TO 
SIMULATE MODE button in the lower A sernej^ *,|fe C«£ Itfitn 4tthef 
continue froa where the simulation was s^u^#lff^^g^WpdOl0. or 
he can begin anew by hitting INITIALIZE followed by START. 

4.3 TIGERS as a Modeling Environment 

In Section 4.2, it was mentioned that one sight differentiate 
among levels at which TIGERS is used. We round that TIGERS, froa the 
point of view of the experimenter described in the last section. Is 
something of a simulating ■acheae §t§gi j&gmjijie can set the values of 
critical parameters and investigate the model's behavior under these 
conditions. But this user level can only exist after a (hopefully) 
valid model has been formulated and the appropriate programming 
completed. In this section we delve more deeply ia$o the logic of 

^■'••TLJ r; ¥ f r i* ► I £ i\& 

TIGERS, and examine the symtefli from tto ptftat af %oWif one using 
TIGERS as a modeling environment. We first discuss model formulation, 
and in the section following we discuss the i m ple m ent n l lpp of thp* ■,. 
formulated model. 

4.3.1 Creating a Model: World Lines 

The task of formulating the emergency room model is formidable. 

°.dom '/T-joW nnriDca-TboH 9H1 pnial! £-& siupH 

The problems faced by the Harkel et al. group (see Section 3.1.2) also 
face the analyst using TIGERS. However, the simulation does allow the 
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analyst considerably more flexibility than that team had working only 
with an analytical model. The harkel et al. group was forced to 
aggregate all emergency room service into the two classes "doctor" and 
"non-doctor" services, whereas simulation can take into account 
seperately such peripheral services as x-ray, lab, outside consultant 
and nurse. Nevertheless, there is no avoiding the difficulty of the 
task of creating the model. 

Developing a model in TIGERS usually means writing a scenario 
describing how given data bases are to be manipulated. A simple 
formalism has been developed for describing the model in terms 
compatible with the TIGERS environment: a world line is a possible 
course of events that a patient may experience from the time he arrives 
at the E.R. until the time he exits. The term is used to refer both to 
the actual sequence of events fmd to the schematic diagram describing 
it. .■■.--.•= •..•i.- 

Consider the following possible sequence of events which an 
accident victim might experience. 

1. Patient arrives at E.R. 

2. Waits in queue. 

3. Called into main treatment room by nurse. 

4. Seen by nurse. 

5. Seen by doctor. 

6. Has blood sample taken and sent to lab. 

7. Sent to x-ray. 

8. Lab test results returned. 

9. Seen again by doctor. 

10. Seen gain by nursed 

11. E.R. treatment terminated. 

12. Admitted to hospital.^ 

This sequence of events can be described by the world line shown 
in Figure 4-10. Another patient with say, a sore throat, might have a 
much less eventful E.R. visit described by the following set of events: 
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Figure 4-10 Example World-line (long) 
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Figure 4-11 Example World-line (short) 
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1. Arrives at E.R. 

2. Seen immediately By nurse 

3. Seen by doctor 

4. Released 

This second sequence of events can be described by the \ world 
line in Figure 4-11. r 

A patient arriving at the E.R. has many possible world lines. 
His visit may last anywhere from a few Minutes to several hours, and his 
treatment i*|yi&e quite simple or <5xtre»ely complex. Hany possible world 
lines can be combined in a world line tree. The world line tree is a 
construct which can, beyjuse^ ^opin^ice*eqseveraAtj^>i«sible sequences of 
events which a patient may experience. Consider for example the three 
world lines in Figure 4-12. A patient in a hypothetical (and highly 
simplified) emergency room might always experience one of these three 
sequences of events. In Figure 4-13, we have a world line tree which 
incorporates all three world lines of Figure 4-12. 

Whereas the world line indicates one definite path of a patient 
through "event space," the world Hee^tr^e indicates a set of possible 
paths. Thus if one is told that a patient has an associated world line 
tree similar to that of Figure 4-1^ he^jgows that the patient's path 
through event space will be--6ne of the three wolrldLj.ines of Figure 4-12. 

Each node of a world line tree with a unique line branching out 
from it indicates^ floiat in space-time where only one thing, one event, 
can happen next. This evetlt»4s indicated by the single branch. A node 
with more than one outward branch, however^ indicates a point in space- 
time where several possibilities exist. In order to indicate the 
likelihood of the various possible events, a probability is generally 
associated with each branch of the; tree such that the sum of the 
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probabilities associated with the outward branches of any node is one. 
It is also desirable to have information about how long the patient 
remains in the state represented by a node. Therefore in addition to 
associating probabilities with each branch, a conditional probability 
distribution function (conditional on which branch is chosen) is 
generally associated with each node. 

It can now be noted that the world line tree provides a 
mechanism to fulfill the need expressed in Section 4.2. In that section 
it was stated that developing a model in TIGERS means writing a scenario 
for the way in which the given data bases are to be manipulated. We 
note that this can be done in three steps: 

1. Formulate a world line tree which incorporates all 
the possible wrid. lioeSr that •ignfcibease^tiatetowith a 

patient arriving to the system. 

:'•■.-■■• =• :'. '.?q^s;i' , -jr*l ,-r* fcsbi *-Sb "6?! J^isnis est? *;:• -• • '- : 

2. Assign a probability to each branch of the tree, 
sueh thst thebsumbof the probebiittse* of eae bramches below 
each node (except the terminal nodes) is unity. 

3. Assign to each node n probability distribution 
functions (where a is ttw Boomer' of branches emanating from 
the node) that give information about how long a patient 
will spend at that node, if he reaches it. 

In real life,, the world line *ree*a«sociat«<* with a patient 
arriving at the E.R. has an extremely larger iwWaVer of branches and 
nodes. However, the probabilities asso c iate *' »4 to mastiaf the branches 
are near zero. The: TIGERS program differentiates among patient types by 
assigning different sets of nodal pdfs and branch probabilities to bach 
type of patient . (The programmer can effectively* assign tfiff efent trees 
to each type by setting certain probability variables t© zero. 1 The job 
of the analyst in designing * model in TI6ERS 1* to formulate trees 
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which ignore the largely irrelevant branches and incorporate the 
relevant ones. Once again we are faced with the trade-off of accuracy 
versus programing overhead. Clearly if the model incorporates details 
that have little effect on paraaeters of interest, computation -time is 
wasted. On the other hand, if not enough detail is included, the model 
■ay not provide useful results. 

Thus although he does have considerably sere flexibility than he 
would have if lie were using analytical Methods stellar to these of 
flarkel at al., the analyst -user of TIG£R3 still cannot avoid the need to 
make careful simplifying assumptions in generating a model. 

The analyst's task is indeed far from simple. "Pruning" the 
tree without invalidating tat model '* results is difficult enough . But 
in addition, once the analyst has decided on the "shape" of the world 
line tree, it remains to assign values to the node edf^is and branch 
probabilities. The only way to do this is to take careful data in the 
actual emergency room and calculate ap p ro p r iate vaioos* from these data. 



4.3.2 Implementation 

We have said that Ti6£R« can be described as an environment in 
which the analyst can imple m en t aa ■nerpewcy room model; Implementing e 
model implies writing a slmelat ion. Even, within T4GIM, the^ analyst 
must still write the simulation; the program will net do this for him 
(at least not yet,), However, TIBERS doe* maker the Job sigeificontly 
easier ; it provides a* set of subroutiaes, eretecols aad data bases which 
the analyst would otherwise havt to design himself , For adlarge class 
of models, the analyst dees, net have to write new routines or create now 
data bases himself. Rather the process of implementing a model usually 
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involves modifying the data-bases and routines already supplied in the 
system. The main features which TIGERS offers the analyst are 

1. A "simulation frame" consisting of a protocol for 
defining events, an events scheduler which keeps track of 
events and executes them at the appropriate times, and 
routines for adding events to the "schedule." 

2. A set of data bases and routines for managing them. 

3. A "basic set" of common events such as "send 
patient to x-ray," "schedule lab report," "generate new 
arrival," "release patient from system," and several others. 

4. A set of graphics routines. Almost all of the 
graphics is handled automatically by TIGERS. TIGERS 
supplies functions such that any graphics handling the 
analyst needs to do is trivial. 

The interested reader should consult Appendix A, in which these 

resources are discussed in depth. 
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CHAPTER V: 
AN I4U>LEHE*fE0 NOOEL 



5.0 Introduction 

Chapter IV introduced the TIGERS environment for modeling the 
emergency room and described interaction with the program. Since it was 
desirable that the environment be demonstrated and tested by at least 
token use, a preliminary model was designed and implemented on the 
system. That model is the subject of this chapter. 

In designing a model, one must continually keep in mind what it 
is he wishes to accomplish with it. Key questions include 1) In what 
aspects of the system under consideration is the experimenter 
interested? and 2) What parameters influence these aspects? 
Specifically, which aspects of a patient's visit to the emergency room 
are being investigated with the model, and which factors associated with 
his visit will have some effect on these items of interest. 

5.1 Design of the Bedel 

Section 3.1.1 discussed which aspects of the emergency room were 
of interest in the current research. We established that for aw 
purposes the emergency room can be viewed as a server system, and that 
the following parameters are relevant indices of the operational 
effectiveness of the this system: 
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1) number of patients in waiting 

rooa queue 

2) tine patient is kept waiting 

before service begins 

3) time a patient actually spends 

in service 

4) fraction of patient service 

-tinw iie4 usefully spent 



Essentially, the task decided upon was to combine the available 
emergency room resources in such a way that the patient time spent in 
the system is kept to a minimum without sacrificing quality of medical 
care, thereby minimizing patient blocked time. 

As has been discussed at length in Chapter III, the definitions 
of blocked time and service time are not easily arrived at. We noted 
that a fine line exists between the two. For purposes of the current 

"**",< -/ . i": :-■■ *"■ ■ ■.■■"**. -i ■■?* "-:~ >*• ■;■ i ■ ;'■■ ■ v <?" 7 '*■■*« '!■ v.s (" f--. '.■ ' : '-, 5 i "5^ tl J* Jri k-*V ? C'V : * . ?*"';' <■' =' " ■ -■- 

model, it was decided that any state in which the patient is using no 
emergency room resource except a bed shall constitute a blocked state. 
Otherwise the patient is said to be receiving service. Thus time spent 
waiting for a laboratory report or under observa* ftew^i»rtootoce««£d*ired ,< 
blocked time. Tn« reasoning behind this dec ts tea is fhat ■• patient 
should be considered blocked only if he tis simply taking up space. " 
Therefore when a patient is in a blocked 9Mttm?i'>lit'vj»:-m*tm&l!CMtUm-i*ti»tt 
some resource is lacking at ttMt mo«em« r ier that soewtliing is blocking 
smooth operation of the system. Thus foieatlw^««ftt^t(ttm#temem«mtidn>^ ; ? >s» 
the four blocked states are waiting for doctor, waiting for nurse, 
waiting for consultant, and waiting to be released from the system; that 
is, doctor blocked, nurse blocked, consult blocked, and exit blocked. 
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In Chapter III it was mentioned that one of the advantages of a 
simulation model over an analytical model a la Markel et al., is that 
the simulation is capable of taking into consideration considerably more 
detail than the analytical model. However, unnecessary detail can only 
impede the modeling effort. It is desirable therefore in building the 
simulation model to take advantage of the capability to explicitly 
manipulate details, but not waste time on non-productive computation. 
Ideally, one wishes to consider explicitly in his model all such factors 
that do have significant effect, while at the same time keeping the 
model as simple as possible. Too much detail is a common pitfall in the 
design of simulation models. 

As a first step in the building of the model, a number of 
questions were formulated which explicitly focus on important factors 
contributing to patient time spent in the system and E.R. resources 
used. These questions served as a basis for the model design. The list 
of questions follows: 

Is the patient's problem especially non-serious? This question 
is important because, as was mentioned in Chapter I, a large number of 
patients requesting treatment at the emergency room have in fact very 
minor problems. (See Figures 2-1, 2-2, 2-3.) Such a patient should be 
dealt with explicitly in the simulation model because he demands rel 
atively little of the emergency room's resources, and his stay is 
generally short. 

Does the patient need x-rays and/or laboratory analysis? These 
are two important hospital resources, the use of which always makes a 
patient's stay in the emergency room significantly longer. Furthermore 
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if these resources are needed, the patient frequently uses more of the 
valuable resource of E.R. personnel tiae. Delays caused by queues at x- 
ray or backlogs in the lab also cause a drain on bed space and often 
constitute blocked tiae. Thus a bottleneck in the x-ray or lab can 
eventually manifest itself in longer service times and longer waiting 
room queues. 

Is an outside consultant required? Sometimes the emergency room 
doctor finds that it is necessary to call in a specialist (e.g. a 
surgeon) from elsewhere in the hospital. Even more than x-ray or lab 
use, calling in an outside physician is a sign that the patient being 
treated has a more complicated problem than most and will therefore make 
relatively large demands on E.R. resources. Furthermore delays incurred 
while waiting for the outside physician to arrive constitute blocked 
time. 

Does the patient require observation? Such patients are of 
concern because they often occupy emergency room beds for hours. 

Is the patient admitted to the hospital proper? This question is 
important because often much time is spent in administrative overhead in 
admitting a patient to the hospital. Such time can be considered 
blocked time. 

Once this set of questions was formulated, the next step was to 
devise a simulation algorithm to implement various possible world lines 
of patients. As stated earlier, the objective was to make such an 
algorithm as simple as possible without sacrificing the ability to 
answer explicitly tfce above questions. The aggregation technique used 
by Harkel et al. was again employed in the design of this algorithm, 
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although fewer simplifying assumptions were made. 

The world line tree upon which this algorithm is based appears 
in Figure 5-1. Briefly the algorithm can be described as follows: A 
patient is seen by the doctor one, two, or three times, depending upon 
the complexity of the treatment needed. On visit one it is first 
decided whether the patient has a problem which can be especially easily 
and quickly treated. If so, the patient leaves the system quickly and 
does not see the doctor again. Otherwise a second visit v ,ii| scheduled. 
It is also during visit one that it is decided whether the patient will 
use the x-ray or lab facilities. 

Doctor visit two does hot occur until after the lab report (if 
it was ordered) is returned and the patient has returned from x-ray (if 
he went). During visit two it is decided whether Iir outside consultant 
physician is to be called. 

The third doctor visit occurs only if a consultant was called. 
The patient may see the doctor a third time when the consultant has 
left. Mote that the more complicated a patient's cases, tAe larger the 
demand on the E.R. facilities and personnel. 

At this p«>int the reader interested in further technical details 
should read Sections A. 7. 2 and A. 8 which describe the model in depth. 
Figure A-5, which is especially useful, is a flowchart which describes 
the algorithm used to implement most of this three-visit model. An 
important aspect of the algorithm is that all decisions based on chance 
are binary; the entire algorithm is based on yes-OF-no questions with 
probabilities of yes (or no) set by the user. It is felt that by making 
all such decisions binary, the user can manipulate the model with more 
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Figure 5-1 World line Tree of Current Model 
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control than he might otherwise. 

A goal of the model design was that major factors influencing 
length of patient stay and amount of resources needed to be explicitly 
variable in the model. These are the variables in which the 
experimenter will be interested. In Section A. 8 are itemized all 
parameters which are set by the experimenter in the current implemented 
model. We note that each of the critical questions mentioned above is 
explicitly considered in the model and can be varied by the 
experimenter. 

5.2 Defining Patient Types 

The world line tree discussed in the previous section represents 
all possible world lines for patients under this tesi a raodel . The 
values assigned to each node and branch, however,, may differ with each 
type of patient, as noted in Section 4.3.1. For the sample model, it 
was decided that three types of patient would be implemented. 

In choosing to implement three types of patient in this model, 
the experimenter divides the population or arriving patients into three 
classes. The criteria upon which this WvUion is-basei depend upon the 
in/ornwtio* tne user wishes to extract frmVke model. By setting 
certain world line probabilities to unity and others to zero, the user 
can effectively assign a single type to all patients with certain world 
lines or classes of world lines. In this manner, the user can isolate 
any particular classes of patients that might hold special interest. 

For example, suppose the user were an emergency room planner 
interested in drug-overdose patients who spend a great amount of time in 
the emergency room bed under observation. These patients, once initial 



?jfl^^^*?s^ : ^i> 



100 

treatment is over, often require little additional treatment. They do, 
however, often occupy a bed for hours, thus making a significant demand 
upon the E.R. resources. The planner might be looking for ways to 
reduce the demand on an overloaded emergency room, and considering 
setting up a special observation area for such drug-overdose patients. 
In setting up his TIGERS model, this user assigns all patients of this 
class to one type, say type 2: First he sets the arrival rate for this 
type to the appropriate number based on data gathered at the hospital. 
Then he assigns the value one to the probability parameter which 
describes the probability of of a patient's undergoing observation. 
Finally be assign* parameter values f of the ether type* , based on the 
fact that patients of these types and petient* of type Z are mutually 
exclusive. 

When the experimenter finally reas the simelatien, he is able to 
explicitly observe hew. much of the overcrowdipe, is being caused by the 
type 2 patients. Also* by setting the arrival rate to zero* he can 
observe the effects of removing this type, entirely fro* the emergency 
room (presumably to the special observ«tion area). We eight net ice that 
the removal of the type 2 patients had-littlf effect, or.he might notice 
that the introduction of the special observation area has solved the 
overcrowding problem of the main, treatment^ room, * , 

5.3 Assigning Parameter Values 

Before running a simulation under TIGERS, the experimenter must 
assign values to all the variable parameters of the model for each 
patient type. Figures 5-2 and 5-3 are the sheets which the experimenter 
must fill out in order to supply parameter values for the currently im 
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Value Variable 



X..3..5 I XR? — Is an x-ray necessary? 

X..3..6 2 LAB? -- Is a laboratory analysis 3 editetf for ? 

1 QO 6 EXIT!?— Does the pVfienT exit iitwnediafely after 
the first doctor visit? 

.5, X, X 3 NUREX?-- If the pattern 1 does jep*V immediately, 
does he see a nurse first ? 

X..2..7 4 ADMIT?-- Is the patfeht to be J b%f>tf ted to the 
hospital proper? 

X, 0, I 7 eNSLT?— Does the patifcrtt see a consult? 

. ..-}-. . '.-y : "\ ■' ?■■■ '.■■'•' -'■ 

X, X..X 5 OUT-AFTER-CONSULT?— If the patient does see a 
consult, does he exif%ime<fitrtei9 dfteV seeing a consult? 

X, .2, .2 8 OBS?-- Does the patient undergo a period pf 
observation before hr leaves the I^itlnl ? 



Figure 5-2 Currently Variable Branching Probabilities 
(Typed numbers refer to position in Probsch vector.) 



*». * * 
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Value Variable 

X,45,45 I ADMITT-- time spent in administrative "red tape" 
waiting to be admitted to the hospital 

X, 25,25 2 ADMIT2-- time spent in administrative "red tape" 
waiting to be admitted to the hospital, after having undergone 
a period of observation 

X, X,25 3 CNSDRT-- time spent with a consult 

X, X, 10 4 CNSLTT-- time spent waiting fora consult 

X, X,20 5 DRCNT — time spent on second doctor visit if 
confute isb^hedutf<| ,,,,. - '■' 3,\* ±.1 '* 

S, X, X 6, £R}M€X ■•--. time spent w4th ^toetor feefore immediate 
exit - : r.,r. v v>-u-. i ' .-■'.'. 

X, \<XiQ J -DRNXLT - t time ej?ent ; with doctor m fiJT»t >dostpr 
visit if lab report but no x-ray is scoediitedL 



is-.itn 'i. 



X, 1,1 8 ,£«N*|$LT -- tijpe, «pe^ with _do«*ftfhan first doctor 
visit if no lab report and no x-ray are scheduled , 

X, 15, X 9 DRT2 -- , time spent witjk rdactor jgvtsecqnd doctor 
visit if no consult is scheduled 

X, X, 10 10 DRT3 — time- spent w,^ doctor prilhirdT|doctbT 
visit 

X, 10,10 1 1 DRXT - - J ime, fte n t'-*'%$m%*hte99 t &- ^^l. 
visit if patient is sent to x-ray 

X, 15, 15 12 EX ITT — time spent in exit blocked state before 
leaving emergency room 

X,20,20 13 EXIT2 -- time spent in exit blocked state before 
leaving emergency room, if patient has undergone period of 
observation ";. ■■-?■: -r;- : . ,-,. ; ri ,- ; v v;frj^:/; ^-5 j , ■.s..^•" 4 



99,3030 14 LAST --time before tdfibrafbry trnaJytW results 
are returned 

12,12,12 15 NURST-- time spent with nurse 
X, 60,60 16 OBSRVT — time spent under observation 
99,12,12 17 XRAYT-- time spent at xray 

Figure 5-3 Currently Variable Means of Random Variables 
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plemented model. The former comprises the probability variables; and 
the latter, the means of the various probability distribution functions. 
(Certain of these variables are currently attached to display buttons. 
The others can all be varied through the teletypewriter. As has been 
discussed in Chapter IV, it is not difficult to attach frequently 
changed variables to display buttons.) The ordered triplets which have 
been filled in the blanks of Figures 5-2 and 5-3 repm«fit*41*fes which 
have been assigned by the author for type** two, *hr%ei aid four, 
respectively, (Bue to an idiosyncracy of the programming, the three 
types are labeled two, three, and four rather then one, two, and three.) 
The values assigned are not based on rigoroes and detailed data. Alt 
they are based upon the author's experience in the Cambridge Hospital 
emergency room and do represent reasonable' valees . 

For this model, the types have been defined as follows: Type 2 
represents the patient with a trivial problem. In the three-doctor- 
visit model, such cases typically see a nurse only once, see a doctor 
only once, end are in the E.H. for a relet ieely short time. Although a 
significant percentage of the patients arriving a* the typical emergency 
room ere in fact of this type, they represent >.m- relatively small Jdrein ^ 
on the system because they use so few resources and their stays are 
short. Type 3 represents the patient who has a some what more serious 
problem, and tfceref ore makes slgnif icantly greater demands on the E.R. 
resources. In the three-doctor-visit model, the Type 3 patient sees the 
doctor twice, and sometimes makes use of various other E.ft. resources. 
The Type 3 patient represents the greatest lead on the E.R., since, 
although the demand per patient is not as great as that of the Type 4 
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patient, the Type 3 arrival rate is generally ouch higher. The Type 4 
patient represents the most serious cases. Type 4 patients always need 
to have a consultant called in fro* the hospital proper, and generally 
demand nore of the available resources than any other type of patient. 
As already noted, however, they generally occur relatively infrequently. 

5.4 Using the, Model -.*-"■: 

The purpose of this section is to coMRiftlcefce *e idea of what it 
is like to sit in front of the CRT and tablet ami we the THIERS 
program. The author requested Pr. Peter nogietlfllpfel of the Cambridge 
Hospital to act as a "token aser" and tp experiment, with the program as 
he wished. We describe here a part of that sets ioa. It weald be 
desirable to have a motion; pic^uf^ to acr le^aay ^e^eliacas^Aon, bat we - 
shall do the next best thing and refer to, the? figures at the end of this 

Section..- ■ "K : V? ft ;;'- 

It i* important that we note? that .the-; displayed ata t ifctics , as 
they are now implemented, caik be :a bit-aisleadinai. «Firs*,bfthe,«iimp>e#»a1 
statistics are based; o» patient*, m temgar ■*• the aasa»*v:NM)lftmm£l«nt*: ' 
visible anywhere on the screen are still in the ^splteap ahdr theref era «to 
not affect the cumulative statistics. SecoiKlly^^ti<e*ts inthe system a 
long time ago have «a such weight in the avaraga* asc iratieitts ^Hist 
released. It aay prova deslrafels «» weight 4ftfeajce^|*jKMfefc vatieats 
heavier in calculations of averages (s» tbat^effectsJ : ofKawre recent 
changes are moras easily discerned) . sBuerini these ifacts In aind; we 
contimte with our description. ^ u a^ i^itmnqsi j-\*-, •;,*., 
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Initially the parameters of the nodel were set as in Figures 5-2 
and 5-3. The program was initialized to five beds, two nurses, three 
emergency room doctors and one doctor on call. At this point, the 
screen appeared as in Figure 5-4. The simulation was then started. 

This hypothetical emergency room appeared at first to be 
functioning smoothly, but this was an illusion attributible to the fact 
that the system begins operation empty — with all beds free and all 
facilities available. As soon as the facility had had a chance to fill 
up, a queue began to form in the waiting room and grew steadily larger. 
It became clear that for some reason this emergency room was not able to 
perform adequately in the face of the demands being made of it. Thus 
after four hours and forty-seven minutes the simulation was stopped, 
with the "stage" appearing as in Figure 5-5. 

Dr. Hogielnlcki commented about there being ten patients in the 
waiting room queue, while four staff members were idle. Clearly, an 
imbalance among the resources was highly probable. We mentioned earlier 
that a program such as TIGERS is especially useful for making the user 
aware of the necessity of maintaining balance among the resources of a 
complex system. Here the two observers (Or. Hogielnlcki and the author) 
were confronted with an example. 

The next step was to try to alleviate the imbalance. It was 
clear that adding more staff would prove fruitless: already there 
appeared to be more than could be utilized effectively in such a system 
Also there were no unreasonable queues at x-ray or in the lab. The 
bottleneck appeared to be that there was not enough bed space to 
accomodate the patients. Thus the next step was to try introducing more 
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bed space into the system. 

Two more beds were added; nothing else was changed. The 
simulation was started again from time zero. The extra beds apparently 
solved the problem. Figure 5-6 shows the system after two hours and 
three minutes of elapsed simulated time. Recall that even with the 
five-bed system, the simulated E.R. appears to function smoothly at 
first because at time zero all beds are empty. Therefore the simulation 
was allowed to keep running, and the two observers watched. 

Several interesting aspects of the system became apparent as the 
simulation ran. First, the characteristics of the various types took on 
special meaning with respect to their respective demands upon available 
resources. Type 2 patients, for example, were interesting in that they 
were not seen in the system for nearly as much time as the others, in 

spite of the fact that the arrival rate of Type 2 patients was 2.0 

;.-,.' ■•■'>r:i <!-»"t ■■-. tot ~: ■">"{. :<z ui'^ ^J'lvi ,'*.,/"..■ - ■<: ' ■ 
patients per hour compared with Type 3 at 2.0 and Type 4 at 0.8. Type 4 

patients, on the other hand, were seen in the system a surprisingly high 

proportion of the time, considering their low arrival rate. Type 3 

patients were clearly the main drain on the system: unlike Type 2 

patients, they used a significant amount of available resources, while 
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their arrival rate was as high as that of Type 2. Although the arrival 
rates of the Types 2 and 3 patients were equal, there seemed to be more 
Type 3 patients because they were in the system so much longer. Dr. Ho- 
gielnicki remarked that if he were considering triaging certain types of 
patients to a clinic in order to reduce the load on the system. Type 2 
patients would not appear to be the type to choose, since they are in 
and out of the system so quickly. 
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The system as it ran seemed reasonably stable. There seemed to 
be an inordinate number of patients in nurse-blocked states (see Figure 
5-6 for example), but the problem did not appear serious enough to 
impede the functioning of the system. The waiting room queue held as 
many as four patients (at 5:Z6--see Figure 5-9), but within thirty 
minutes had decreased to zero (Figure 5-10). In fact, at 6:13 (Figure 
5-11), the E.R. was practically empty. In spite of the fact that the 
number of patients in the nurse-blocked state seemed to indicate that 
another nurse would not have been wasted, the two extra beds solved the 
overcrowding problem of the five-bed system. 

At this point Dr. Hogielnicki, considering the rate at which 
arrival rates were increasing at the Cambridge Hospital Emergency Room, 
wondered whether this seven bed system would be able to support a 
heavier load. Switching to Modify Node (Figure 5-12), he changed the 
arrival rate of Type three patients from 2.8 to 4.8 patients per hour, 
thus increasing the arrival rate of patients «f all three types from 4.8 
to 6.8 patient* per hour. 

The CONTINUE button was then hit, and the simulation continued 
with the higher arrival rate.« By 8*16, all seve* beds were full (Figure 
5- 13 ) . Nurse-blocked states continued tee be evident; By 9 : 20 , there 
were four patients in the waiting room queue (Figero #-14). The two 
observers began to suspect that the Mejhef^aWi*al*<*a*e might be more 
than the system could comfortably cope with, At2 1**18"* the waiting room 
queue had reached a length of 8 (Figure 5*15) Van4 the observers decided 
that their hypothetical emergency room weald net; handle the increased 
load. 
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The question of how to bring the system back into balance once 
again arose. Dr. Hogielnicki decided that the present configuration 
might simply not be large enough, but he was not convinced that the two 
extra beds had brought the system into balance. Recalling the 
inordinate number of nurse blocked states that had been observed 
throughout the simulation, he decided to alleviate that problem by 
adding two extra nurses, and then to continue the simulation. 

The two extra nurses clearly made a difference. Nurse-blocked 
states were no longer a problem. In fact the system seemed to be 
running smoothly again. By 11:34 the waiting room queue length was down 
to three (Figure 5-16), and by 14:03 (Figure 5-17) there was only one 
patient in the waiting room. 

5 . 5 Statistics ■ i ■■.■•:,..• 

Recall from Chapter IV thet one of the display buttons controls 
the display of statistics ia SIMULATE lmtimuiF*r*mmc*tmitemtti»k,z4lt' ! 
has been decided that the following statistics be displayed* 

1. number of patients who have beea treated ;v.w> 

1. average time in waiting room queue 

3. average service tine per patient treated 

4. average blocked U»« j «-••., ■ .^ ' 
** average doctor time per patient jjreatanVu-r -v-i.-.^ <■ - 

As described in Section 5*1, items three and fo*r poaed some difficulty 
in their definition. The relevance of these five statistics is 
discussed in depth In Chapter III. 
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Dr. Hogielnicki has suggested that it would be constructive to 
add two additional sets of displayable statistics to the package (also 
adding two corresponding buttons to SIMULATE node). The first would 
display the idle tiae (i.e. tine not busy) of the various resources. 
This would be expressed as a percentage of total tine. Included would 
be such infonnation as doctor idle time and bed utilization. The 
second set of statistics would itemize the causes of blocked tine. Thus 
instead of simply displaying average blocked tine (as in the current 
inplementation); average doctor blocked tiae, nurse blocked time, 
consultant blocked tine and exit blocked tine would be displayed. As we 
have stressed throughout our description of the TIGERS system, the 
program is intended to evolve with changing needs. This change 
suggested by Doctor Hogielnicki is one example. 
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CHAPTER Vt: 
PUTTING THE RESEARCH IN ITS PROPER PERSPECTIVE 



6.0 Introduction 

This concluding chapter attempts to summarize what TIGERS is, 
what it is not, and what it night become. It begins with some warnings 
intended to preclude possible misinterpretation of the program and its 
displayed output. It then looks to the future, pointing out possible 
paths of future research suggested by the current work. Finally it 
looks at the present, artd the potential offered by TIGERS- like programs. 

6.1 Warnings 

A program that communicates with the user through intuitive 
channels in addition to more rigorous ways can be valuable, but 
associated with such a program are inherent dangers of which the user 
should be wary. A TIGERS-like simulation carries pitfalls along with 
its blessings. The purpose of this section is to point out explicitly 
some of the more important for which one should be on guard. 

The following point was made in Chapter IV, but is reemphaslzed 
here because instinct tends to make it easy to forget: as of this 
writing the TIGERS display in simulate mode has nothing to do with the 
actual layout of the emergency room's facilities. That is, the display 
does not necessarily bear any resemblance to the actual floor plan of 
the facility, nor do any of the routines which manipulate the various 
resources take the architecture directly into the simulation. The fact, 
for example, that the x-ray facility is located three minutes' walking 
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distance from the main treataent room is reflected in the model only in 
that that time is a factor in calculating the time that a patient spends 
at x-ray. Such a model could be built -- a model which would allow the 
user to manipulate the possible arrangements of a facility,. But the 
author contends that J^..-m^»c%^-oI- i Xl^^^i^^L^m.^}^%vl_ parameters 
on the performance of the system are s ec o nd a r y wjioft compared with the 
effects of parameters considered in the p/cesent rasearch. 

Another critical point which we have mentionejd before but hears 
reemphasizing jU the importance of, . basing 4*ci*ion& on a vaUd »odel. 
It is easy to convinca oneself that the figure* oii,.-the. CRT automatically 
model the real world. We must continually remind ourselves that this is 
so only if we take the trouble to obtain valid data. This can be the 
most tedious task of the modeling process, but it must not be avoided if 
the model is to have value. 

The TIGERS simulation lends intuition and therefore 
understanding -- information it communicates is net obscure. On the 
other hand it is easy to be misled by its Inherent credibility; a 
situation might seem so obvious or real on the screen that it becomes 
too easy to avoid questioning the validity of the model. The simplicity 
and clarity of graphical communication is a mixed blessing. It becomes 

sv- ; ■ A.,r.^ ■'-■ -■ -.. :^jl!" ;:,;;' ajors • tulim;z fli t**Q^i^ £513d!T •-•".? orw' ~- 
natural to simply assume that what is being observed represents a real 

•:';.'v-—- ■■•■;■,■"-■' ""■<'■■■'-- -'■■'-- "i ■• i ; -;;-:^ ;'' f iM)-''i y->FK, 4 psi5'? -'i: ■ :,- •■*..■'.■;&, .<. ■< '■ '.- ' 
life situation. The phenomenon is something of an extension to the well 

known "the-computer-said-it-therefore-it-ls-true" phenomenon, in which 

we tend to accept facts as gospel simply because they are printed on 

. ■--;' - . .■ - ,-. -■■:-. --..'.- v-i-5 -..-oxb o*!i'Tcsf i rf- i« rr" ^s? c ■.,.~-;-c«-;>" 
computer print-out. Granted, this phenomenon is observed mostly in its 
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numerous exploitations by the advertising industry; but it is real, and 
one should be wary of it. 

6.2 Future Work 

The current research touches several fields IB which relatively 
little has been done. The idee of nwdt ling systems similar to the 
Emergency Room characterized by small silt <i;i; thane buildingl and 
great complexity has not been as popular as modeling more expansive 
systems. Also, the idea of Interactive graphical simulation has been 
used hardly at all, especially in the world 1 of public systems. In 
exposing the tip of several icebergs, TIGERS -*frfti§§* many questions about 
the parts still hidden. 

6.2.1 A Valid Model 

Before a tool like TIGERS can contribute towards making a 
hospital run more efficiently, it must be based upon a world line tree 
and parameter values which have been proven beyond reasonable doubt to 
constitute a valid model of the emergency room. Such research, although 
it would involve many hours of data gathering and analysis, would allow 
the program to become a practical tool instead of an academic 
demonstration. 

A large class of unanswered questions has to do wth the nature 
of models of the E.R. Little is known, for example, about the marginal 
utility of detail. The whole issue of the (negative and/or positive) 
marginal utilities of aggregation with respect to model validity needs 
to be investigated. The example model implemented by the author was 
motivated by the hypothesis that an E.R. model can be significantly more 
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accurate if it takes into account individually such services as x-ray, 
lab, and outside consultation, rather than aggregating then all together 
under the category "non-doctor service." This is a reasonable 
hypothesis, but it has not been proven. The •ere, detailed podel does 
not avoid the need for aggregation, even though viewer., assumptions are 
needed for the more detailed than for the simpler one. It is 
conceivable that the emergency room is so complex that the additional 
detail introduced buys littla accuracy over a model incorporating only 
two classes of service. Research into which factors increase the 
validity of models of the emergency rooms, especially research,, 
investigating the marginal utility of detail, would be worthwhile. 

One aspect of the investigation Mentioned above would be to 
construct the "ultimately detailed" model involving a world line tree 
with hundreds of nodes and branches. The development of such a detailed 
model would, of course, necessitate a large effort, but might offer the 
best solution to the problem of modeling the emergency room. 

It seems reasonable to believe that the "optimum" model would 
fall somewhere between the two stage Harkel et al. model and the 
ultimately detailed model described above. It would be interesting to 
construct several models at various intermediary levels of detail. 
Validity checks could be run and results could be compared. Conceivably 
one might notice a level of aggregation at which additional detail made 
no significant difference in results. 
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6.2.2 Analysis Routines 

Another worthwhile addition to TIGERS would be a set of analysis 
and optimization routines. At present the user viewport serves to 
indicate imbalance in the system, and the program allows the user to 
vary his trial parameters to attempt to overcome the imbalance. But the 
program does not of itself make any analysis or, suggestions . It would 
be useful if TIGERS did have analysis capability. 

For example, i% might prove useful for the program to be abje to 
decide whether a user-implemented change has had ; a statistically 
significant effect on the system. Consider the following:. Suppose that 
the waiting room queue is seen through the viewport as obviously too 
long, and the experimenter postulates that adding a .nurse to the system 
will alleviate the problem. He notices a small change in the queue 
length, but does not know whether the change is larpe^ enough to be 
statistically significant. If an anlysis package existed as pert of 
TIGERS, it might incorporate the necessary tools for determining the 
answer to this significance question. 

A more sophisticated analysis package might even be able to make 
suggestions. Such a program would not only decide whether 
significant, but it might actually suggest the change. Thus in the 
example above it might suggest that the experimenter try adding a nurse 
to the system. Implementation of such, ft package would. .involve [design 
of a set of heuristics which make use of such statistics as accumulated 
patient nurse blocked time, accumulated doctor blocked time, etc. 
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6.2.3 The Analyst's Tool 

The main research effort of the work reported here was directed 
towards development of TIGERS as an administrative tool and 
communications medium, (hie can communicate with a particular model on a 
highly interactive level. One logical next step is to create a tool 
which allows design of models at the same level of interaction. The 
present implementation of TIGERS is based upon a single world line tree 
which the author designed as a reasonable example. A number of other 
world line trees were possible, but since the present research was not 
primarily concerned with the design of a model, only one tree was 
actually implemented (i.e. used to generate a simulation). Although the 
analyst might wish to implement a number of "trees In the TfTGtRS 
environment, such implementations are not necessarily easy. To some 
extent, the ability to set parameters to zero for various types of 
patient allows limited ability to experiment with different world line 
trees; but complete flexibility to change the tree does not exist. 
TIGERS provides a useful set of subroutines and a highly functional man- 
machine interface, but there is no escaping the fact that changing a 
world litre tree into a working simulation can sometimes be a lot of 
work. 

The proposed "analyst's tool" would do this work. Essentially, 
it would accept as input a formulated" world line" tree 7 . ' It would then 
generate the appropriate subroutines and actually write the simulation 
program to bring to life the given tree. Thus the black box in TIGERS, 
which now must be filled by the modeler(s), would be filled 
automatically by this proposed program. There is good reason to believe 
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that such a program is well within the realm of possibility, but we must 
realize that we are discussing a project which would probably represent 
at least as much effort as has already been expended Mius far on the 
current research. If it were implemented, it would extend to the 
experimenter the same flexibility to experiment with various trees as 
TIGERS now allows one to experiment with a given, model . 

6.3 Why TIGERS? 

In this repWt. we have introduced the idea of the graphical 
interactive simulation of a public system. Although the idea has as yet 
hardly been explored, it seems to show promise as a "bridge over the gap 
between the administrator and the technical analyst. TIGERS is an 
analytical tool which can interact directly with thei administrator as 
well as the analyst, and whicii hopefully can therefore serve as a focus 
in co-ordinating the insights that both have to H»rfeir. 

The simplicity of graphical communication is especially 
important in the world of public systems. Hd special 'training is needed 
to understand the language of graphics, and thus it might serve to 
communicate where other media might prove less fruitful. A hospital 
administrator, for example, who must explain to officials i in city 
government why he will need to expand his facilities to a certain Size 
before the end of the next five years can lucidly make his point with a 
model that has graphical output. Furthermore --'"anil this point becomes 
very significant in the public sector -- graphics is dramatic . It can 
provide persuasive evidence for demonstrating a need. Weak points and 
bottlenecks in the system become obvious as crowds of figures start to 
overflow the screen. 
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The intuition added by graphics becomes especially significant 
in modeling a system such as the hospital emergency room in which 
balance is so critical. It was discussed in Chapter III that in the 
E.R.p an optimum amount of any resource is optimum only when in proper 
balance with the other critical resources and with the demands made on 
the system. A thousand beds is probably no more useful than ten if 
there are only two doctors available. Graphics is especially useful In 
a system where a balance must be s truck among: many AUb c sy^tem& of a 
complex system; the user viewport allows a view of tha entire system.. 

The human engineering aspects of a TiGERS-1 ike program are 
important . The, nature of the medium introduces psychological aspects to 
the analytical process which are usually in^gnif leant or do not exist. 

For example, interactive graphics can add an element of 
flexiblity which is perhaps unobtainable through other media, 
flexibility which is desirable for ,*. number of! reasons. First the user 
can 4<| much more useful work per unit time, yfitn^ lid observes that the 
execution of the simulation is jio longer interesting* he can "flush" it 
immediately, and waste no more time wi.th ;(£. ,J&t sjir^^siflgly, 
flexibility, also encourages •Wi^^Wpfto&Jfaj&tifc otherwise not h 
consider worth the trouble. The user U ancourjtged : t% be, creative 
because it becomes easy to try new ideas. Also significant is the 
immediacy of reinforcement, which alsp encourages crAativity. A user 
often will not bother trying oujt more far-fetched ideas if he, Jtas to go 
to any trouble to implement then or "ait for results, and yet it is well 
known that occasionally a far-fetched idea will turn out to be the 
beginning of an exciting new way of looking at something. 
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Another human engineering aspect of the TIGERS- like program is 
the very fact that such programs are more interesting to work with than 
the relatively dry non-graphical packages. Administrators are often 
loath to become deeply involved in rigorous analytical methods. The 
graphics medium makes the subject considerably more palatable. 

Dr. Nogielnicki has pointed out that hospital administrators 
are often mistrustful and/or uninterested in the more technical methods 
of analysis, even though such methods might sometimes be applicable to 
problems facing them. He suggests that a TIGERS- like program might 
stimulate interest in such methods, because such a program cannot answer 
all the questions that it raises, and thus stimulates an interest in 
tools that can. 

The hardware upon which the present system is Implemented is 
currently too expensive for practical application in most situations, 
but graphics technology is developing rapidly and is fast entering the 
realm of practicability for smaller installations. Both from the points 
of view of the analyst and of the public agency decision maker, the 
medium represents a potentially constructive addition to the field of 
public systems analysis. 
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GLOSSARY 



Poisson Distribution 
A distribution for random events which assumes that the 
intervals between events are independent and exponen- 
tially distributed. Events occurring according to a 
Poisson distribution are completely random, unscheduled 
events. In models described in this report, patient 
arrivals are assumed to be Poisson. 

Primary Care 
That part of the health care system which represents 
the patient's first level of contact with medicine. 

Queueing Theory 
A branch of mathematics which deals with waiting line 
problems. In a typical queueing problem, a service fa- 
cility provides service to customers who arrive in some 
random manner and require some variable amount of time 
to be served. Queueing theory describes such features 
of the service process as the queue sizes, queue delays 
and server idle time. 

Service Time 
In queueing theory, the length of time required to serve 
a customer. In the emergency room, this corresponds to 
the time a patient spends in treatment after leaving the 
waiting room queue. 

Triage Nurse 

A nurse stationed in the emergency room who directs 
incoming patients to. sources of treatment appropriate to 
the urgency of their needs. A triage nurse might, for 
example, order that x-rays or a blood sample be taken 
before the patient enters the main treatment room. 
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APPENDIX A: 
DESCRIPTION OF THE TIGERS PROGRAM 



A.O Introduction 

In this appendix, the actual programming of TIGERS is discussed. 
The data bases are described, and the routines that pan ipu late then are 
explained in depth. Although the appendix is rather complete in its 
discussion of the various subprograms which comprise TIGERS, it does 
not, of course, replace the listing of the program itself . But except 
for the reader who intends to modify the program, a copy of tjie listing 
is not a necessity. 

Describing a program is difficult in that it is almost 
impossible to avoid alluding to topics not yet covered, but forward 
referencing has been avoided to as large an extent as possible. The 
structure of this appendix is such that the broader, and generally more 
important, topics are discussed first. The reader who is interested 
only in getting a general feel for the program need read only the first 
part, although he may wish to skip afterwards to the description of the 
graphics handling routines. Section A. 7. 2 might also hold special 
interest in that it describes, among other things, the algorithm upon 
which the currently Implemented model is based. The reader who is also 
interested in details of the program will want to read the whole 
appendix. 

This appendix serves two purposes: 1) it allows the interested 
reader to examine to almost any depth he chooses how the TIGERS program 
works, and 2) it allows the analyst who is interested in working with 
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TIGERS to become familiar with the protocols of how data structures are 
set up and manipulated, and to discover resources that the program 
offers him. 

A.l HUDDLE 

Every effort has been made to keep the discussion which follows 
independent of the HUDDLE language in which the program is written. But 
occasionally it becomes necessary to use a phrase or two of the language 
to clarify a point. We therefore outline here a few essentials which 
will clarify the references to HUDDLE which are made. 

HUDDLE is a so-called list processing lenfuage based upon 
certain types of data structures. A group of objects enclosed in 
parentheses forms a list: 

(< object) <object> . . . <object>) 
A list can be comprised of no objects (the empty list) or many objects, 
and the objects can be of various types such as numbers, variables, 
vectors, or other lists. 

A vector is similar to a list, but it is enclosed by brackets 
instead of parentheses: 

[<object> <object> . . . <object>] 
The differences between the two types of structures have to do with the 
manner in which they are stored in the computer. The objects in a 
vector can be changed easily, whereas the number of objects in a list 
can be changed easily. 

The structure which is used to indicate function application is 
the form, which is delineated by angle brackets (<>). The first element 
of the form is taken to be the name of the function being applied, while 
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the remaining elements of the form are taken as arguments. Thus the 
form 

<FUNCTB 1 2 A> 
would apply the function FUNCTB to the arguments 1, 2 and A. The form 

<SIMULATE> 
would execute the function SIMULATE which takes no arguments. 

Variables in HUDDLE can take on two values, the local value 
(LVAL) and the global value (GVAL). The LVAL is assigned by the 
function SET, while the GVAL is assigned by the function SETG. Thus 

<5ET VI 4> 
would assign the local value 4 to the variable VI, and 

<S£TG VI DOG> 
would assign VI the global value DOG. Note the values of a variable 
might be anything — other variables, numbers, vectors, lists, etc. — 
they are not restricted to being numbers. Tne loeal value of VI can be 
referred to as ".VI"; and the global value, as ",V1". Thus after the 
call to SET above, "VI" evaluates to VI, but ».V1" evaluates to 4. 

Certain functions in HUDDLE exist to manipulate lists. This 
set of functions lends great power to the language, but we discuss here 
only a very small subset. The function NTH applied to a list returns 
the n'th element of the list, where the list is the first argument to 
NTH, and n is the second argument. NTH is generally called using a 
shorthand method: by "applying" a number to a list, the n'th element of 
the list is obtained. Thus if we said to HUDDLE 

<SET LISTA (79 CAT 2.5)>. 
Then 
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<1 .LISTA> 
returns 79, and 

<2 .LISTA> 
returns CAT. 

The reader should bear in aind that this discussion of HUDDLE is 
non-rigorous and serves only to clarify certain phrases used in Appendix 
A. The reader interested in HUDDLE should consult Gregory Pfister's A 
MUDDLE Primer?, in which the language is explained in depth. 

A. 2 The Events Scheduler 

The heart iof THIERS 4$ ithe exeats *eftt(feaer*M*«hicb is named, 
surprisingly enough, SCHDLR. I* is «dittStt«ed in greater detail in 
Section A. 6 . a, Iwt ejg introduce it here . te 0*4*1 #e^l»der***id> the, 
scheduler, one mu*t first exajKtee l,ts a mftc i et a d 4a ta bases. Its three 
teey ?*truetitres .ar* the patient , tear evaa* , »* the? «ohedu»le .. 

The petteat Hi the TIfiERS environment is represented iiy a- vector 
of the following eight components: o ■ .-;-«:r v--. n^ , f ;- ; ?^- •"'■■ 

1. Number of doctor visits ; 

2. Pointer to bed location 

3. Conflict flag (lection A. 7.2) --■■ •. ,j ; ',;v; 

4. Time of arrival 

5. 'Time of entrance to main treatment room 

6. Hinutes of doctor time 

7. Minutes of blocked time 

8. Patient type 

The event is a vector of length three with the following format: 
[<time> <routine> <patient>]. 
The <time> is the time at which the scheduler is to execute the routine 
<routine>. <patient> is the patient that is of primary concern to 
<routine> as it executes. This patient is generally referred to as the 
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current patient. 

The schedule is the list of events to be executed; there is 
only one schedule, so it has been piven a name, SCED. SCED is an 
ordered list; the elements (i.e. events) are arranged such that the 
events whose associated routines are to be executed first are first on 
the list. 

It was stated in Section 4.1 that TIGERS is an event paced 
simulation in which the scheduler executes routines associated with 
events which manipulate the data bases and generate more events. A 
simulation run under TIGERS is basically a loop which repeatedly calls 
SCHDLR. (This loop is desribed in Section A.6.1.) SCHDLR does the 
following: 

1) Delete the next event from SCED. 

2) Wait f if necessary) until tae*sf*elaied£time*is equal to 
the time of the event. 

3) Execute the associated routine. 

4) Return to the routine (not executed by SCHDLR) which 
called SCHDLR. ^ 1^ 

The "wait" in step 2 is not characteristic of the event patted 
simulation. But because one of the reisons d'etre of a TIGERS-like 
simulation is to lend intuition, it is desirable not only to maintain 
the proper order of execution of events, but also to maintain a 
simulated temporal flow. The program therefore maintains its own 
simulated time stream. The ratio of the speeds of simulated time to 
real time is one of the parameters whose value is set by the user. (The 
speed of the computer limits this ratio to a maximum of approximately 
one hundred.) 
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To say that a routine generates another event, is to say that at 
some point in soae routine it is decided that soara other event is going 
to happen at some future time. In order to realize execution of this 
future event, the routine oust inform the scheduler. Two steps are 
necessary: 1) Create the event; i.e. create the vector containing the 
time, routine, and patient. 2) Place this event in the list SCED in its 
proper place in order. The utility function which any routine calls to 
send an event to the scheduler is called ADSCD (ADd to SCheDuler), 
AD5CD accepts the three arguments of time, routine, and patient; 
generates the vector, and places the event in its proper place in the 
list. AOSCD and SCHDLR are discussed in detail in Section A. 6. 3. 

A. 3 Other Key Data Bases 

In addition to SCED, there are eight other important data bases: 

1) queue of patients in waiting room (WAITQ) 

2) queue of patients in beds waiting far a doctor (DRQ) 

3) queue of patients in beds waiting for a nurse 
(NURSQ) 

4) queue of patients waiting for x-ray facility (XRQ) 

5) BEDSTR 

6) CNTSTR 

7) PDFSCH 

8) PROBSCH 

The four queues all operate in a first-come-first- served 
manner. In the TIGERS program they are structured as lists of patients, 
and they are manipulated by two utility functons: The routine ADTOQ 
accepts two arguments, a patient and a queue, and appends the patient to 
the end of the given queue. The routine LEAVEQ accepts one argument, a 
queue, and returns the next patient in line. These routines are 
discussed in greater detail in Section A. 6. 4. 
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Note that the queue of patients waiting for lab test results is 
not on the above list of data bases. This is because in the current 
implementation of TIGERS, the lab queue is not first-corae-first-served. 
Rather, the lab is viewed simply as a black box to which requests are 
made for service. (The time that it takes to honor such a request, 
however, is a function of the number of requests outstanding.) 

BEDSTR and CNTSTR are vectors in which are stored several key 
parameters of the program. They contain all of the information which is 
dynamically displayed on the TIGERS display during a simulation. These 
two structures are of such a form that the information that they contain 
is accessible by both the simulation routines and the graphics routines. 
The form of CNTSTR is: 

[a b a b a b ...], 
where a is always or 1, and b contains a parameter value, a is 
strictly for use of the graphics routines: when a is 1 it indicates 
that the associated b has been changed since the screen was last 
updated, and that the value should be updated on the display. CNTSTR in 
the present implementation of TIGERS, contains six parameter value pairs 
U b): 

1) length of x-ray queue 

2) length of waiting room queue 

3) number of nurses available 

4) number of E.R. doctors available 

5) number of doctors on call 

6) number of patients waiting for lab reports 

BEDSTR, which contains information about the main treatment room, is a 
vector of the form 

[abcdeabcde ...] 
where a is as in CNTSTR, and b, c, d, and e define the state of one bed. 
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Recall from Section 4.2.2 that each bed has associated with it four 
fields, b is associated with field four. In the present implementation 
of TIGERS, field 1 can be in one of three states; field 2, i'n one of 
four; field 3, in one of seven; and field 4, "in one of four. Thus b can 
be either 1, 2, or 3; c and e, an integer between 1 and 4, inclusive; 
and d, an integer between 1 and 7, inclusive (see Figures 4-4, 4-5, 4- 
6). Note that TIGERS knows the state of a patient by examining the 
states of the fields of his associated bed. 

The structures PDFSCH and PROBSCH are associated with the world 
line trees of the various types of patients in the TIGERS system. 
Section 4.3.1 describes world line trees and explains how each node is 
associated with a probability distribution function and each branch with 
a probability. The program manages this information by associating with 
each world line tree two vectors, one containing the probabilities 
associated with all the branches, the other containing the means of the 
probability distribution functions. Thus each node and each branch of 
each world line tree is associated with a position in a vector. 

Recall that one world line tree is associated with each of the h 
types of patient in the TIGERS model. PDFSCH is a vector of n vectors, 
the n vectors containing the branch probabilities or the >n jby||es,of 
patient. PROBSCH is also a vector of n vectors, the e|ef«nts of each of 
which are the means of the pdfs. Thus PROBSCH and PDfSCH stffe f 11 the 
numerical information associated with any world -line trees in the model . 
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A. 4 Classes of Functions in TIGERS 

The purpose of this section Is to introfuce°tlie various types of 
subroutines that comprise the TIGERS program. the sections following 
will examine these subroutines one by one. 

Before discussing the various functions and types of functions 
in the program, however, a word on notation is in order: for ease of 
discussion, we may speak of "executing an event," which is a simpler way 
of saying "executing the function associated with "an fveiit." Also the 
reader should regard the words "fuhction;* ^routine," and "subroutine" 
as synonyms. Routines in TIGERS take various numbers of arguments, and 
some return values. But function characteristics will be made evident 
by explicit explanation or from context — not by any naming convention 
which differentiates among the three terms. 

Within the TIGERS program can be found the following nine 
classes of functions: 

1. Event functions are routines which are a part of the 
simulation per se. These are the routines that manipulate 
the data bases which represent aipatts e^tai" 1 iiirglircy'' 
room. It is event routines which send events to the 
scheduler, and it is also event roll ihe* which are executed 
by the scheduler. 

2. Random variable functions (r.v. functions) are functions 
which Use random neaber generators t6 generate random values 
of random variables. They are used by event functions to 
decide which branch of a world* HfttrlrieV ttPWfci fbllbwed 
by a given patient at a given tine. It is r.v. functions 
which introduce randomness into the simulation. 

3. Simulation functions are functions such as SGHDLR which, 
although not event funcions, are an integral part of the 
simulation. 

4. Utility functions are useful aids to the programmer who 
is constructing event functions. They provide something of 
a metalanguage within IttJDDtl which facilitate* the- writing 
of event routines. 
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5. rime /unctions maintain tbe sieHjlated t}»e flow. 

6. Graphics functions nanage tfe«^i«tti|ses oa Jtjjp scope and 
maintain the dynamic display. 

7. Button AanfiUin? functions are routines which are called 
whenever their associated buttons are bit by the user. 



8. Interrupt Handling functions i are- rout J.ne« wn,Lcb are 
called whenever a clock interrupt is generated by the 

computer's injenpipt jys*em. n^#Ml^fl*9i«al Wfl**i the 
clock and 2.) decide which button handling routines to call 
when buttonj.are^hit, , ,, .,, : ^, ,, ^., „,, 



9. W00i£ /gectipis are standard #rUh« J iq and structure 
manipulating functions which are "built in" to HUDDLE. They 
are used to construct other functions of all *Wf*-.-- 
Al though they are absolutely essential to programming within 
TIGfl^thejf are not discussed ^rtber in this repprt, and 
are included in this list only for completeness. {!] 



Not all TIGERS functions fall UDiqualy into one of these nine 
classes, but generally the classes art distinct. Jn the following 
sections we examine TIGERS subroutine by subroutine. AJL1 of the major 
functions are discussed* but for .some, of tbe.mpstu,m|.nor,. the program 
listing should be consulted. In the sections below tbe functions will 
be organized by class and will be.., discussed ip tb^pnder of the above 
list. Where useful, flowcharts are provided and/or an example of how 
each routine is Invoked is g^ven- ; 4^^j$i|j^ 

of the effects of celling the routine is also given. .These sections are 
written as an aid to anyone planning to wrltjit.jsjroojroms; in %he TIGERS 
environment. 



A. 5 Manipulation of CNTSTR and BEPSTR — 

Uti^,ty,|un^ons ^n, yA^ ; #Dp^,affo;syBl 

BEDSTR and CMTSTR are a very ieportant parjfc of TIGERS. Any 

simulation within TIGERS references them frequently; it is therefore 
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highly desirable that manipulation of these critical data bases be as 
simple for the analyst as possible. The routines UPD, VAL, ADD1 and 
SUB1 exist for this purpose. 

UPD is a function for manipulating BEDSTR. It takes three 
arguments, the third of which is optional. The first two are integers, 
while the optional third is a patient (vector of length eight). If the 
third argument is not Supplied, the current patient is assumed- The 
effect of a call to UPD is to set the field indicated by argl in the bed 
associated with arg3 to the value of arg2. Also UPD sets the bit which 
informs the graphics routines that they should indicate the change on 
the display. Thus if BEDSTR currently looks like this 

[0 21530211302152022630215 4], 
and UPD is called: 

<UPD 3 4 .CPAT> 
where .CPAT is the patient in bed 3, then BEDSTR is changed to: 

[0 2 153021131214202 2 6 3 2 1 5 4]. 
Thus the status of the patient in bed three is changed from being 
treated by a nurse to waiting for a doctor. Furthermore, the next time 
the graphics routines look at BEDSTR, they will notice the 1 
(underscored above) and then reset the 1 to and make the correct 
change in the displayed status of bed 3. 

VAL, ADD 1, and SUB 1 are functions for manipulating CNTSTR. 
Recall that CKTSTR contains the values of certain parameters, and that 
CNTSTR also contains information for the graphics updating routines. 
The routines VAL, ADD1, and SUB1 make it easy to refef to the elements 
of CNTSTR by separate names without being concerned about the graphics 
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information. Instead of XQL referring to the actual value of the 
length of the x-ray queue, it actually points to the position in CNTSTR 
where this value resides. The call 

CVAL .XQL> 
returns the length of the x-ray queue. Similarly <VAL .WQL> returns the 
length of the waiting room queue, and so on for NNURS, NDR, NONCL, and , 
LABQL. (See the description of CNTSTR in Section A. 3.) ADD1 is used 
for incrementing any of these values, and SUB1, for decrementing. Thus 
If CNTSTR looks like this: ' 

[000-201020 10 1], 
and the analyst wishes to increment the number of nurses available, he 
uses ADD1: 

<ADD1 .NNURS>. 
CNTSTR then looks like this: 

[0 00 -212020 10 1]. 
As with the change to BEDSTR, the graphics routines will make the 

appropriate change in the display, and reset' the 1 (underscored above) 

to 0. r-i-f-- 

A. 6 Simulation Routines 
A. 6.1 SIMULATE 

SIMULATE is the main simulation loop mentioned in Section A. 2. 
It is fully explained by the flawehart in Fiaure Ar-l. STQPBIT ts a bit, 
which, if set, causes the program to exit from tee loop. CCOUNT ia* 
count of the number of events executed. 
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Figure A- I Flowcharts of RSTART, START, and SIMULATE 
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A. 6. 2 Starting the Sim ulation - - 

RINITIALIZE, telN IT , R START, and START 

Before the SIMULATE loop is entered at the beginning of a 

simulation (as opposed to re-entered after having stopped an already 

executing simulation) the simulation must be initialized. First the 

user hits the INITIALIZE button on the display. This cause execution of 

the routine RINITIALIZE. which does nothing but call REMIT and NPASS. 

RE INIT does the following: 

1. initialize BEDSTR — all beds free, 



2. initialize CMTSTR -- waiting room empty, all resources 
available, 

3. initialize all cumulative statistics, 

4. initialize all first come, first served queues (see 
Section A. 3) -- make them all empty 



5. initialize display of all cumulative statistics. 

NPASS, the routine which updates the display to reflect changes In; 
CMTSTR and BEDSTR, is discussed in Section A. 0. After the user has hit 
the INITIALIZE button, he starts the simulation by hitting START. This 
causes execution of the routine RSTART, which does the following: 

1. Call START. 

2. Call NPASS. 

3. Initialize count of events executed (ECOUNT) to 1. 

4. Initialize the interrupt handler which updates the clock 
in the display. This clock updating routine is called 

UPC LOCK, and is described in Section A. 11. 

5. Bitter the simulate loop by calling 3 fHULATE . 



153 

The routine START, which is the first routine called by RSTART, 
does the following five steps: 

1. Initialize the simulated time to 0. 

2. Turn off STOPBTT (in case it has been left on). 

3. Initialize the events scheduler by setting the Initial 
value of the schedule. The statement 

<SET SCED 
<[<+ .NOH 

<EXPDI5 </ 60.0 <2 .LAHBDAS»» 
•<MEWP 2> 
[0 2]])> 

declares that SCED is a list of length one. Its one element 
is the event vector whose elements are the time J that the 
event is to be executed (calculated by calling EXPDIS); the 
routine NEWP, which generates a patient arrival, (Section 
A, 7.1); and the dummy patient vector [0 2J. 
(NEWP is one ef the few routines which has no "associated 
patient".) 

4. Generate and send to the scheduler instances of the 
event NEWP, so that patients of all possible types will be 
generated. 

5. Call the scheduler. This executes the event NEWP just 
sent to the scheduler. NEWP of course generates other 
events, and so the simulation is on its way. 

Flowcharts summarizing the entire initialization procedure 
(RINITIALIZE, RSTART and routines that they call) are given in Figure A- 
2. 

A. 6. 3 SCHDLR and ADSCD 

The events scheduler was introduced in Section A. 2. The purpose 
of this section is to describe the routines SCHDLR and ADSCD in greater 
detail. 



154 



START REINIT 



START RINITIALIZE 




I 



SET BEDSTR 
AtlPBEDS FREE 



rr 



TT\ i. 



INITIALIZE 
CNfSTR 



SET ALL 
CmKULATIVE 

■'SUmsT&s 

TO ZEFfO 



INITIALIZE 

ALL 

MkfQ QMEUES 



INITiALrZE 

BJIgLAY 

OTSTWfSTICS 






Figure A-2 Flowchart of RINITIALIZE and REINIT 
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A flowchart for SCHDLR is given in Figure A-3. Recall that if 
.L is a list, then <1 ;L> is the first element of the list, <Z L> is 
the second element, etc. 

SCHDLR takes no arguments. Mien it is called, It removes the 

next event from the list SCEO; waits, if necessary; and executes the 

routine associated with the event. Consider for example, a state of a 

simulation iiti TIGERS where SCED is as follows r 

([37.685173 <SNDNS PRFD> [0 6 37.685173 37.6#5173 3}] 
[92.209408 <NEWP 3> [0 6 37.685173 37.6*5173 3]] 
[96.171992 

<FRDR> X 

[110 18.469403 18.469403 66.055544 3]] 
[97.171992 

<SNDXR> 

[110 18.469403 18.469403 66.055544 3]] 
[107.17436 

<HEWP 2> 

[1 6 24.505186 24.505186 .69831634 2]] 
[483.71264 <NEWP 4> [0000000 2]]) 

If at this point the program calls SCHDLR 

<SCHDLR> 
the program waits until the simulated time is greater than 37.7 minutes 
(if waiting is necessary), and then the event 

[37.685173 <SNDNS PRFD> [0 6 37.685173 i7 ? 685.173 3]] 
is removed from SCED, and the routine NEW is executed. wTien SCHDLR 
returns to the calling function, SCED is fch*n«e# tocsoaething like this: 
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([41.656325 <FRNRS> [0 6 37.685173 37.685173 3]] * 
[41.956323 <PRFD> f.0 6 37.685173 37 .685W 3»]] * 
[92.209408 <NEWP 3> [0 6 37.685173 37.685173 3]] 
[96.171992 

<FRDR> 

[110 18.469403 18.469403 66.055544 3)J 
[97.171992 

<5NDXR> 

[110 18.469403 18.469403 66.055544 331 
[107.17436 

<NEWP 2> 

[16 24.505186 24.505186 .69831634 2]] 
[483.71264 <NE\*P 4> [0 U 2JJ) 

Notice that in addition to the fact that the first event from before the 
call to SCHDLR is no longer there, certain other events (indicated by *) 
have been added to the list. These new events were created during the 
execution of MEWP; ADSCD was called to eI^i*-^sVhe* events and send 
them to the scheduler. 

ADSCD does two things: create an event vector, and insert this 
vector in SCED. The function takes three arguments, a time, a routine, 
and a patient- The third argument is optional, and if it is not 
supplied, the current patient is assumed. The call 
< ADSCD 41.656325 '<FRHRS> [0 60 37.685173 37.685173 3]> 
would cause the the first event marked by * above to be generated and 
added to SCED as shown. 

A. 6. 4 APTOQ and LEAVEQ 

Recall that first-come-first-served queues are simply ordered 
lists in TIGERS. ADTOQ and LEAVEQ, introduced in Section A3, are the 
routines used for manipulating th«se queues. Tfle routines are simple, 
but it will be constructive to give examples of their use and of effects 
of their Use. Consider a point in a simulation in which all beds are 
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occupied and there is a queue of length four in the waiting room. The 

TIGERS waiting took queue, WAITQ, might look like this: 

([0 47.946094 2] 
{0 49.379954 3] 
[0 53.499452 4] 
[0 59.360199 0^3]) . ;j 

Say it is time 63.740902 and the event NEWP, which generates new 

patients, is executed. NEWP notices that there are no free s toeds, and 

adds the new patient to the queue by calling ADTOQ 

<AOTOQ WAITQ [0 63.740902 3]>. 

After the call, WAITQ is larger: 

([0 47.946094 2] 
[A J»4».JJft9&4 0,0-4 3} 
[0 53.499452 4] 
[0 59.360199 3] 
[0 63.740902 3]) 

Say a few minutes later a bed becomes free; then the routine CALL IN is 

called to "call in" a patient from the waiting room. CALL IN uses the 

function LEAVEQ to get the "next in line" from the queue: 

<SET NP <LEAVEQ WAITQ>> L 

At this point, .NP is equal to [0 47.946094 Z], and CALL IN has 

its new patient. Furthermore WAITQ has been updated to 

([0 49.379954 3] 
[0 53.499452 4] 
[0 59.360199 00 3] 
[0 63.740902 3]) 

A. 7 Event Functions 

Ip this section we discuss the, event functions currently ; 
available in the TIGERS environment. It is important to keep in mind 
while reading it that most of these functions are designed around the 
model described in Chapter V. That is, the event functions, at least 
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the less general ones, are necessarily related to the world line tree 
being implemented. It is difficult to say which of the existing 
functions would be obsolete -- or which would need to be rewritten, or 
which new functions would need to be added -- if some other model were 
being implemented. It suffices to remember that the program Is intended 
to evolve to meet changing needs. 

There are some definitions and phrases that should be kept in 
mind In studying these events. First retail that all event functions 
are executed only by the scheduler, and that associated with each event 
function executed by the scheduler is a patient. The event functions 
are written assuming the existence of this patient; in the context of 
discussing an event we shall refer to this patient as the current 
patient and to the associated bed as the current bed. 

Often we shall speak of "sending an event to the scheduler." 
Recall that this process involves two steps: 

1. Decide when the event is to be executed. This decision 
is made using r.v. functions to generate a random value for 
the time increment involved. 

2. Use ADSCD to create the event and place it in its 
correct position in the ordered list SCED. 

Also we shall sometimes speak of sending an event to the scheduler "tr 
be executed immediately." This simply means that the scheduled time of 
execution of the event will be the current time; thus the event will be 
executed immediately after the current event. Sending an event to the 
scheduler to be executed immediately thus avoids having an event 
function called by other than the scheduler. 
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Finally recall that four fields are associated with each bed. 
The utility function UPD, which updates the values of these fields, will 
occasionally be used in this discussion, especially in the flowcharts. 

A. 7.1 HEWP 

NEWP (NEW Patient) is the event function which generates 
arrivals to the system. Unlike most evjmt functions it takes an 
argument, the patient type of the patient to be generated. Execution of 
NEWP effects the simulated world in two ways. First a new patient «f 
the specified type appears in the simulated emergency room requesting 
treatment. The patient is either, assigned. tp f j^ bed and a nurse, or, if 
one or both of these are not available, the patient enters the waiting 
room queue. The second major job of NEWP, is Jp,. perpetuate Itself so 
that more patients will arrive in the future. This it accomplishes by 
generating a new NEWP and sending the event to the scheduler. 

The algorithm of the routine can be described by tbf following 
steps: 

1. Generate a random value of an expoqantial random 
variable. Use this value to dete^Re^e ^arrival time of 
the next patient of the current patient type. 

2. CaU ADSCI? to create the next instance of,M|Wp for the 
current patient type. 

3. Create a new patient (recall that a patient is described 
by a vector of length eight). 

4. Increment the number ofjjatiants in tin? system. 

5 . If there is a wa i ting room qu«ue , aj^l, ,tne E <n»w jm tient to 
queue. Then return to the scheduler.' If there is no queue, 
proceed to steps 6 and 7 V 

6. Find an empty bed, and assign the patient to that bed. 
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7. Generate (send to the scheduler) the event to assign a 
nurse to that patient. 



Since each NEWP perpetuates the arrivals of only one type of 

patient, it is necessary for the initialization routines to initialize 

SCED such that one instance of the arrival of each type of patient is 

scheduled. Thus for a model with three patient types, the initial 

schedule might look like this: 

([3.5183036 <NEWP 3> [0 Z]] 
[53.986576 <NEWP 2> [9 2] J 
[347.16065 <NEWP 4> [0 2] J) 

After SCHDLR executes the first event on the schedule at time 3.5183036, 

the schedule might appear as follows: 

([3.5183036 C&IDNS PRFD> [0 10 3.5183036 3.5183036 3]] 
[7.1731240 <NEWP 3> [0 1 3.5183036 3.5183036 3]] 
[53.986576 OfcW 2> CO O 2 J] 
[347.16065 <NEWP 4> [0 2]]) 

Note how the event NEWP executed at that time perpetuates Itself 

by creating a new similar event to be executed at time 7.1731240. The 

event <SNDNS PRFD> was generated to call in a nurse to treat the new 

patient. (We might remark as an aside that Type 4 is apparently a very 

rare type, since the first Type 4 arrival is not scheduled until almost 

six hours into the simulation.) 

A. 7. 2 PRFD and ASSIG N 

PRFD (Patient Ready For Doctor) is the event that is executed 
whenever a patient is ready to be seen by a doctor. This might occur 
just after a patient has been admitted to the emergency room, or upon a 
patient's return from x-ray, or upon any number of other occasions. The 
exact time is, of course, a function of the model that is implemented 
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(hereafter referred to as the current model). PMO, more than any other 
event, is dependent upon the current model, for it is PRFD, or at least 
its subfunction ASSIGN, which is always rewritten with each 
implementation of a world line tree. Oversimplifying only a bit, one 
might say that PRFD in a TIGERS simulation has the following tasks: 

1. If a doctor is available, assign this doctor to the 
patient; if not, place the patient in a .queue of patients 
waiting for doctor. 

2. Decide duration of visit with (jtact^^.aatd, determine next 
event in world line of patient. 

3. Generate the event to deassign the, assigned doctor at 
the appropriate time. 

PRFD generates all events which represent items for which a 
doctor is usually responsible. [\ r ^^%tv^ i ^4X^^^7^^^ tr .at^i, 
consulting physicians from the floor are ordered by the event PRFD. The 
flowchart for PRFD appears in Figure A-4; although it is largely self- 
explanatory, some discussion is necessary. Step Z above is performed by 
the subroutine ASSIGN which will be discussed below, but first we 
examine the implementation of steps 1 and 3, referring to Figure A-4. 

First the conflict flag is set to W. This is the heretofore 
unexplained flag, mentioned in Section A.2, which is the third element 
of the patient vector. This flag is used by the pr^gfap to avoid 
generating redundant instances of PRFD for any g4^en patient. If it 
were .not for this r flag* any patient for whom both x-ray and lab tests 
were ordered might find himself seeing the i 4p^or ; -, ) twic^i a* the same 
time, since the events associated witfc both return ^from x-ray and return 
from lab generate the event PRFD. 
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Figure A-4 
Flowchart of PRFD 
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After setting the conflict flag, the program checks to see if 
there is a lab report outstanding for the current patient. If there 

is, the patient is placed in a Itf* Hocked state until the rfcpont corns 

' : V ■■■'.. I \ Olfi ; ■ 

in. It is assumed that there is no point in visiting a doctor a second 
time until lab results ordered during the first doctor visit are in. 
The event PRFD will again be scheduled for the patient for the time Just 
after the lab report is scheduled '-to arrive : . 

If there is no outstanding laboratory report, the program 
attempts to assign a doctor to the patient. It first checks for 
available emergency room personnel. :" } ^l nw&rwrwvmttwM*, tt decides 
whether the patient should be placed in a doctor dlocAed state or 
whether an attempt should be made Jo call in a doctor on call, fn the 
present implementation, a doctor on call iv sought only if there is a 
waiting room queue. Of course if no doctors on call are available, the' 
patient is still placed in the doctor blocked state. 

The temporary variable TEV *i* a device which is used to deassign 
the correct doctor when step 3 is^exwdfted. If an emergency room doctor 
was assigned, TEV becomes the event FRDR (fr« a „JL s IUJtolUtorJ.^ilL* i doctor 
on call was assigned, TEV becoaes FRNCL Jfre^ doctor on call). ThW 
when the. event TEV is executed at the end oflPRFD, the correct 
deassigning routine is executed. 

The subroutine ASSIGN, which is internal to PRFD, is the heart 

of the implementation of the world line tree in TIGERS. It is ASSIGN 
which decides what' a patient's next event is to be and when it is to 
occur. ASSIGN generates this event and sends it to the scheduler,. It 
therefore changes With each world Hine tree implemented. Chapter V 
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discusses the world line tree which has been implemented as a part of 
this research. Figure A-5 gives a flowchart for ASSIGN which is based 
upon that tree. 

Before further discussing ASSIGN, we digress at this point to 
introduce random variable functions, the use of which is necessarily 
understood before ASSIGN can be explained. Random variable functions 
(r.v. functions) constitute the mechanism; employed by TIGERS to 
introduce randomness into the simulation. A* of* this writing there are 
two types of random variable functions, the .booZean type is called wi,th 
no arguments, and returns simply 99s or no (actually T or FALSE . As 
mentioned in Chapter V, the model is structured such that associated 
with certain key questions are probabilities of the livelihood of 
certain events occuring which are set by the experimenter. Each boolean 
r.v. function is associated with one of these probabilities. The 
function, when called, generates its yes or ho value by considering the 
probability and calling a random number generator. That is, it is as if 
the function were to precisely weight (bias) a coin, and then flip the 
coin to generate a value. The test model is so structured that each of 
the key questions listed in Chapter V has associated -with it a 
probability and a boolean r.v. function. In Figure A-5 each of the 
decision boxes 6, 17, 18, 20, and 24 represents a call to a boolean r.v. 
function, and thus also represents a point at which the experimenter 
assigns a probability. 

The second type of r.v. function is the time (t.r.v.) function. 
T.r.v. functions are used to determine values for random time intervals 
when they are called for. They are called with no arguments and. like 
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boolean r.v. functions, use a random number generator and a parameter 
set by the experimenter to generate a value. This user-set parameter is 
usually the mean of the probability distribution function associated 
with the value being generated. Thus, if the associated parameter of 
the t.r.v. function DRXT were, say, 30.0; a likely result of the 
statement 

<SET TIMEVALUE <DRXT» 
would be to cause the variable TIHEVALUE to be set to, say, 37.61438. A 
repetition of the statement would set TIME VALUE to some entirely 
different value. For more information on random variable functions, see 
Section A. 8. 

We now return to our discussion of ASSIGN and Figure A- 5. 
Recall from Chapter V that the model assumes one, two, or three visits 
with the E.R. doctor, depending on the complexity of the treatment 
necessary. This is reflected in the three main subsections of the 
flowchart, each of which is associated with one of the branches 
emanating from the decision box which examines the number of doctor 
visits (box 3). Generally speaking, ASSIGN does the following: 

1. Increment the number of doctor visits. 

2. Decide which event(s) should be scheduled next for the 
patient. 

3. Call the appropriate r.v. function to decide how long 
the current doctor visit will last, and therefore when the 
next event is to be scheduled. 

4. Pass this information (time, event, patient) to AOSCD, 
which creates the event and puts it in its proper place on 
the schedule. 
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Let us exaaine in nore detail the three main branches of Figure 
A-S. Clearly branch one (first doctor visit) is the aost complicated. 
The first decision (box 17) is whether the patient is relatively easy to 
treat, in which case an iaaediate exit is scheduled, if this is the 
case, the appropriate t.r.v. function is called (box 23), and then 
another decision point is reached (box 24). The question here is 
whether or not the patient needs to see a nurse before leaving. Once 
the appropriate event is scheduled, the function returns to the calling 
function, PRFD. 

If an ianediate exit is not scheduled, aore questions reaain. 
First, is a lab report necessary (box 18)? If so, Make the appropriate 
arrangeaents (boxes 11 and 12). Then set the conflict flag and 
continue. Is an x-ray to be taken (box 20)? If so, call the 
appropriate function to generate doctor tiae (box 21) and send SNOXR to 
the scheduler. Then return. If no x-ray is necessary, set the 
appropriate doctor tiae (boxes 13, 14, and 15), and send the event to 

the scheduler (box 16). Then return. Different t.r.v. functions are 

;-•;.,• ■ .: ■ -■ '• \ ■--,'.:: '■'-'■".:■ on: i*r-qt **. r f s"<-knvl; ,{i ■'*•■■■'.'' ■■ j • . 

called, depending upon whether a lab test was scheduled or not. 

Branch two is considerably siapler than branch one. On the 
second doctor visit, the only aajor decision is whether a con*u«fe64fl* 
physician is. to be called or not Abm^U ir*fr^ J>enJUl *«pt ** called, 
the event of his arrival is scheduled (bows 7 and 8 k> o*h«*mise the 
patient is scheduled ^Jaaan (poxes .MrA MbWunoTat ?.t:i? ^s. 

Finally, branch three is the simplest. This brawsh i* only 
reached when a doctor sb%% the patient after the consultant leaves. 
This calling in a doctor for a third tiae signifies that this patient 
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has needed much of the emergency room resources. Branch three simply 
schedules the patient's leaving after seeing the doctor, the third time. 

A. 7. 3 SNDXR, XRAYFR, and LABRET 

SNDXR is the function which transfers the current patient from 
the main treatment room to the x-ray facility. This involves the 
following steps: 

1. Increment the number of patients at x-ray. 

2. Update field 1 of the current patient ~to ' f ^(at^x-ray) . \^ 

3. If the facility is already in use, add (using A^TQQ) 5 the 
current patient to the end of the waiting 
for x-ray, and return to the scheduler. 

4. Otherwise, start the patient's x-ray service. This 
involves calling the routine XRAVT to generi 

value for the time spent at x-ray, and using AdSCD to send 
to the scheduler the routine (XRAYFR) to return the patient 
to the main treatment room. 

5. Set the conflict flag to 1. 

6. Send to the scheduler the event PRFD to be executed just 
after XRAYFR. 

XRAYFR is the event alluded to above which releases the current 
patient from the x-ray area. Its algorithm is as foiiows: 

1. Decrement the number of patients at x-^ray. 

2. Update field 1 of the current patient to Z (in main 
treatment room). 

3. If there is no x-ray queue, simply return to the 
scheduler. 

4. Otherwise, remove the next in line from the queue, and 
make this patient the current patient, then for this new 
patient repeat steps 4, 5, and 6 of SttDXR above. 
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LABRET Is the event which returns a lab report on a patient to 
the main treatment room. The actual request for the report is made by 
the doctor in PRFO (in ASSIGN). When the request is made, the number of 
reports pending in the lab is incremented, the time until the return of 
the lab report is calculated (an r.v. function is called), and the event 
LABRET is sent to the scheduler. LABRET does the following operations: 

1. Decrement number of lab reports pending. 

2. If the conflict flag is set to 1, then return 
immediately to the scheduler. 

3. Otherwise check whether the patient is at X-ray. If so, 
return immediately' to the scheduler. " 

4. If the conflict flag is set to and the patient is not 
at x-ray, send the event PRFB to the scheduler to be 
executed immediately. 

A flowchart of LABRET appears in Figure A-*. 

A. 7. 4 DLCW, CLTARV. CLVDR, AND CLVOUT 

DLCW, CLTARV, CLVDR, and CLVOUT are the functions that handle 

that part of the patient's world line tree related to the visit of a 

consultant physician (if necessary). All are extremely simple . DLCW 

(Doctor Leave, Consult Wait), if it is scheduled, is scheduled during 

the second doctor visit in ASSIGN. It does th>e following tasks : ;; 

1. Update field 3 to 3 (waiting for consultant). 

2.. Call the r.v. function CNSLTT'to'find out how long the 
patient will be in the consult blocked state. 

3. Send the event CLTARV to the scheduler. 



g. z.-\ -4 -si^sSi^SS^i Jif^SS^r-rSfc 



^®^^^H^^^t?3^»^^?f^« ***- ■ ** " ■' 



^H>S*S!P?*f-?**^l**?^- 



171 



START LABRET 



I 



DECREME^T 

# lM 

REPORTS 

QUTSI&NIMNa 



UP*D 2 r 




SCHEDULE 
PRFO FOR 



Figure A-6 Flowchart of LABRET 



.-^-TgsSsftTa'w*" *— •"» - *- "—**■- <■ *** v -* ***- -**- *~ ~ "^^w^Hs^^^^^f^^^^^^^S^r^PS^i^ 



172 

CLTARV (ConsuLTant ARriVe) is called Oflly by CLTARV. Its 
algorithm: 

1. Call the r.v. function CNSORT to find out how long the 
consultant will be with the patient. 

2. Decide whether a third doctor visit* Wjijl i% necessary by 
calling the r.v. function OUT-AFTER-^OHSflffc * , 

3. If a third visit is to be scheduJh^i^li^jWii event 
CLVDR to the scheduler. Otherwise, send CLvfjUT. 

CLVOUT and CLVDR are similar; each has only two steps. The 

first is to update field 3 to 1 (i.e. no longer be i«g served by the 

consultant). The second is to schedule for immediate execution the next 

event: CLVOUT schedules OUT, and CLVDR schedules pWFD. 

i; 
A. 7. 5 CALL IN, SNDMS, and FRNRS 

CALLIN is the routine which reaoves a patient from the waiting 

room queue. It is not called unless a bed is available, and this bed is 

the current bed when it is called. It does the fallowing: 

1. Remove a patient from the waiting room,'<queue by using 
LEAVEQ c vavv 

<SET NEWP <LEAVEQ WAITQ» 

2. Assign the current bed to the new patietft. (i.e. set 
element 2 of the new patient vector to the position in 
BEDSTR of the current bed.)- _- iCSri'^r 

3. Update field 1 of the current bed t^£ (indicating 
presence of a patient) and field 4 to t^HtM^o/ithe new 
patient. - , - 

4. Send to the scheduler to be executed immediately the 
event to call in a nurse to treat the itew patient. 

5. Record the time of this event as the time of "beginning 
of service for the new patient (in element 5 of the patient 
vector). 
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SNDNS is the event which assigns a nurse to a patient. It 

takes one argument, an event, which informs the routine which event is 

to be sent to the scheduler when the nurse* s treatment of the current 

patient is over. Thus 

<SNDN5 PRFD> 

would cause a nurse (if available) to be assigned to the current 

patient, and it would cause SNDNS to send the event PRFD to the 

scheduler to be executed whenever current nurse treatment ended. The 

call 

< SNDNS RISE > 

would similarly cause the event RLSE to be executed when nurse treatment 

was over. 

FRNRS is the routine which deassigns a nurse from a patient and 

reassigns the nurse to a patient waiting for a nurse (if any such 

patients exist). This procedure is accomplished by the following steps: 

1. Update field 3 of the current patient to 1 (no server). 

2. If no other patients are waiting for a nurse, simply 
increment the number of available nurses and return to the 
scheduler. 



Otherwise : 



3. Use LEAVEQ to remove the first patient from the queue of 
those waiting for nurse service, and assign the nurse just 
freed to the new patient. (Update field 3 of the new 
patient to 5). 

4. Decide how long this new patient will be treated by the 
nurse, and send the event FRNRS to the scheduler to be 
executed at the appropriate time. 

5. Send to the scheduler the event representing the next 
event in the new patient's world line after the nurse 
leaves. (It knows this event because the event which placed 
the patient on the queue of patients waiting for a nurse 
also placed on the queue information describing this event.) 



*»-«*« „ 
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A. 7. 6 RLSE. OUT, and PDWO 

RL$E (ReLeaSe) releases a patient froa the system when all 
treatment is over. It involves four tasks: 

1. Incorporate statistics of the current patient into the 
cumulative statistics. 

2. Dec resent the number of patients in the system. 

3. Remove all traces of the current patient from the 
current bad* J i . e . Update aUi ' WM A* f £f ***s I? * • > ■ 

4. If there is a waiting room queue, send the event CALL IN 
(to call a patient from , tbfpwad^^ room into the free bed) 
to the scheduler to be executed immediately. 



OUT is the function which prepares the patient to leave the 
emergency room system. The flowchart for OUT appears in Figure A-7. 
The routine first decides whether the patient is to undergo observation 
or not. In calculating the value of the boolean random variable on 
which the decision is based V "the probabilities of the* branches at this 
point iB.iiN.wpr.XHk^ ^fhaJatient 

is to undergo an observation period, the duration of this period is 
calculated, and the event PDWO (Patient Done With Observation), is sent 
to the scheduler. Otherwise* tb^eyen^RL^Is *p$ 3 $£ : the scheduler. 
PDWO does nothing ; more Shap "_, pfnfFl!!!^} ^''fSff^nf^th^f ^ f jb§l»r T awnnetr 
to OUT when PDWO is not generated. Note that the probability 
distribution f unction asspciajed; wi^inej-tiiee^f^i^lr' *S ? sjlieduled 
to be executed varies, depending upon wneinlr*1tne patient is to be 
admitted to the hospital or releasad to the outside world. 
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A. 7. 7 FRDR and FRNCL 

FRDR and FRNCL are the routines which deassign an emergency room 
doctor and a doctor on call, respectively, from alpatient. The two 
routines are similar; in fact, they are the same, except the first 
increments the number of available emergency r«0*/d(^ters while the 
second increments the number of doctors on call. Both call the 
subroutine FREED which takes one argument describing which data base to 
increment. Thus <FRDR> is nothing more th*n < FREED .NDR> {where NDR is 
the number of available doctors), and <FRMCl> is eimply <FREED .NONCL>. 
We describe below the algorithm for FRDR: 

1. Update field 3 of the current patient to 1 (no server). 

2. increment the number of available E.R. doctors! 

3. itna patient is waiting for abactor, simply Saturn t© 
thJe scheduler. "._,,. _ __. ._ ... 

i 

4. Otherwise remove the first patient JtroafJtha. queue of 

those/ waiting and send to the scheduler PRFD (foil the new 
patient) for immediate execution. r > 

A. 8 Random Variable Functions 

Random variable functions, which introduce randomness, non- 

■■ — ■ ' /;¥?: ■..; ijij\i. :, ; 

determinism, into the simulation, have already jbaoa.1 introduced in 

' i epiTS'-rATS ' 

Section A. 7. 2. The r.v. functions of a simulation depend -very much upon 

} 
the particular model being implemented. In this tec t ion we describe the 

facilities available for creating r.v. fuactions^pamd list those 

5 f*,T : 

functions that have been implemented for the carnfQt test model. 

R.v. functions are generally trivial. Writing a boolean r.v. 
function requires only the utility function RrtNDOfl, whi<h is called with 
no arguments 
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<RANDOH> 
and returns a number between and 1. Let us say that the probability 
of a yes is P; and of a no, 1-P. Then the algorithm for the desired 
boolean r.v. function is as follows: 

1. Call RANDOM. 

2. If the value returned is less than P. then return the 
value T. 

3. Otherwise, return FALSE. 

For tiae random variable functions, the algorithms can get a bit 
more complicated but are still basically simple. In the presently 
implemented model all time increments are assumed to be characterized by 
exponentially distributed random variables. Thus for the present model, 
the only necessary utility function is EXPDIS, which accepts one 
argument representing the mean of an exponential distribution, and 
returns a random value of the random variable described by the 
distribution. Analogous utility functions for other probability 
distribution functions are being written. 

The present t.r.v. functions do nothing more th%h call EXPDIS 
with a given mean, but it is conceivable that more complex functions 
might be more accurate, and" therefore desirable. For example, one night 
want to introduce a fixed delay plus an increment characterized by an 
exponential or gaussian distribution. Such routines are not difficult 
to create. 
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The following eight boolean r.v. functions exist in the present 

configuration: 

XR? -- Is an x-ray necessary? 

LAB? — Is a laboratory analysis called for? 

EXIT1? — Does the patient exit immediately after the first 
doctor visit? . f . . .. >: . H , n?r .. b .. 4V - ? . 

NUREX? -- If the patient does leave inaediately, does he see 
a nurse first? 

ADMIT? -- Is the patient to be admitted to the hospital 
proper?.. . ^ ,. t . - , ,, , ', ,.,..,:.,- -^r,.*-, -,•,•■:;■ ■ 

CNSLJ? -- Does tiie patient see a consultant? 

QUT-AFTJE&-CPHSULT? .--. If r the pap lent does. t £«e a- consultant, 
does he exit immediately after the consultation. 

OBS? — Does the patient undergo a period of observation 
before he leaves the system? 

There are also seventeen time random variable functions: 

ADHITT '— time spent in administrative *red tape" waiting to 
be admitted to the hospital 

ADMITZ -- time spent in atei^n^ajlys^e^ 

be admitted to the hospital, after having undergone a period 

of observation . . .._. , . .,...,, -,..■.,.? j, v ,„ 

CNSDRT ~ time spent with a consultant , 

CNSLTT — time spent waiting for a consultant ^ u .-. : 

DRCNT ..-,-. time spent on second doctor visit 4# jepn^uljiant is 
scheduled 

DRIttEX — time spent with doctor before immediate exit 

DRNXLT -- time spent with doctor on first doctor visit if 
lab report but no x-ray is scheduled 

DRNXNLT -- time spent with doctor on first doctor visit if 
no lab report and no x-ray are scheduled 

DRT2 — time spent with doctor on second doctor visit if no 
consultation is scheduled 



!■*»■--■*,■»!!*, #«»««*...-•—,-- » -----^r. ^l,: s -^ ? -.,„,^. , -w> / _,.^^o_-<«»t.. -.^^^^^^ ■■ — . . . ; 
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DRT3 -- time spent with doctor on third doctor visit 

DRXT — time spent with doctor on first doctor visit if 
patient is sent to x-ray 

EXIT? -- time spent in exit blocked state before leaving 
emergency room 

EXIT2 — time spent id exit blocked state before leaving 
emergency room, if patient has undergone period of 
observation ■,-. • xz-.-^-z ~u, ?.nc r *.••.? • 

LABT — time before laboratory analysis results are returned 

NURST -- time spent with nurse * 

OBSRVT — time spent under observation 

XRAYT — time spent at x-ray 

A. 9 Graphics Functions 

In this section we discuss the graphical updating of the display 
in Simulate Mode. Maintaining the buttons (most of which are in Modify 
Mode) also involves graphics, but we discuss button handling in a 
separate section. 

Aside from the button handling routines and the functions which 
actually create the pictures (which are not described in this document), 
there is only one main graphics function, NPAS5. Recall that a 
simulation in TIGERS is a loop which repeatedly calls SCHDLR. In this 
loop each call of SCH&LR is immediately followed by a call to NPASS 
(Figure A-l). HP ASS is the routine which looks at BEDSTR and CNTSTR and 
updates the display to reflect any changes made during the execution of 
the last event. 
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The display in Simla te Hode is composed of three types of 



pictures: 



A. The static framework. This includes the lines 
delineating the various sectors, and the identifying labels. 

B. The beds in the Bain treatment area and their associated 
fields. Relevant information is in BEDSTRi 

C. The collections of stick figures which represent! groups, 
of various types of persons. Relevant information is in 
CNTSTR. As of this writing these collections iaciude 

1. patients awaiting lab analysis results 

2. patients in x-ray area 

3. available emergency rooasdoctors 

4. available doctors on call 

5. available nurses 

6. patients in waiting room queue 



Clearly NPASS need be concerned only with types B and C. The routine 
updates the two types of pictures in two distinct phases, type C 
followed by type B. We discuss the two phases separately. 

For maximum execution speed, each of the six collections of type 
C is updated by its own updating routine. These routines comprise the 
elements of the vector RFQS. Thus each element of RFQ5 corresponds to 
one of the element pairs of CNTSTR (Section A. 3). The type C pictures 
are updated using the following algorithm: 

1. Check item i (i.e. the i'th pair) of CNTSTR. Was it 
changed , during the execution of the las t event? ->?. ( I .e ; is it 
flagged with a "1"?) 

2. If no, increment i, and go back to 1 to check the next 
.item^rXNTSTR*, .• . ;^-_ 

3.. If yes, call (i.e. execute) element i of RFQS, thas? 
updating the displayed value of the associated value in 
CNTSTR. Then increment i, and go back to 1 to check the 
next item of CNTSTR. 



'^^ai^figBifc^^^ 
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When i exceeds the number of items (currently six), the updating of the 
type C pictures is complete. 

The type B pictures are updated in a similar manner, except 
BEDSTR is the main data base instead of CNTSTR, and only one routine is 
necessary, not six. All the beds can be updated by the same routine. 
Essentially the algorithm consists of checking each bed, updating those 
that have been changed and skipping those that have not. The 
programming is such that the numbers in BCOSTR associated with each N d 
field are used to call the approriate picture. 

A. 10 Time Functions 

Ah important part or the TIGERS environment is the provided 
simulated time flow. There are two time functions: STIHE, which 
returns the present simulated time in minutes, and CttAWJESPEED, which is 
used to alter the rate of simulated time flow. 

There are four internal variabilis jse<l by ihese time functions: 

TSCALE is the number of thirtie|hs of a real second in one 
simulated minute. -■.■'-••■■-' «'■- *•• *u**v ,■{>.- 

LAST I ME is the absolute real time that CHAMGESPEED was last 
called. 

LAS THIN is the simulated time that CHAMGESPEED was last 
called. 

TTEHP is the absolute real time that STIHE was last called. 

The "absolute real time - is the time which Hs soppi lift by the computer's 
clock. This time is given as the number of thirtieths %f a second since 
the operating system was last started. 
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STIftE takes one argument, the current value of TSCALE. It 
returns a floating point number which is the simulated time in minutes 
since the simulation was initialized. It does the following steps: 

1. Read the absolute real time from the computer's clock. 
Call it T. 

2. Calculate the simulated time as 

LA5TH1II ♦ ((T - LASTJME) /^SCAL^,, r 

ST I ME is written in assembler language rather than HUDDLE because HUDDLE 
cannot access the clock and because the function is called so of ten that 
execution speed is critical. 

CHANQESPEED also takes one argument, the new value of TSCALE. 
It does the following: 

1. Set LASTJUM to the current simulated time 

2. Set TSCALE to the given new value 

3. Set LASTIQI to the present absolute real time 



CHANGESPEED also sets the value of the variable 0FTE8, which is related 
to the frequency that the displayed clock is updated. 

A. 11 Interrupt Handling Functions 

HUDDLE has a facility through which HUDDLE programs can access 
the PDP-10'S half second clock interrupt. TIGERS has' two interrupt 
handling functions which i|«e this ^ac4|ity^ f U?CM?C£ t which updates the 
displayed simulated time, anj CHEOtBI, wb*ch makes the program 
interactive. The reader should beax iii MliiU Af 5 £«Jli ? *£ e 
descriptions below , that these fu nctions ere executed every half second . 
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The variable OFTEN, whose value is set by CHANGESPEED, defines 
how often the display will be refreshed. It is set such that the 
displayed clock is refreshed approximately as often as it changes. Thus 
if a simulated minute were equal to five real seconds, the clock would 
be updated about every five seconds. 

UPCLOCK ( UPdate. CLOCK) does the following: 

1. Decide whether it is time to update the displayed clock. 
If not, return to the simulation. 

2. Decide whether the hour needs to bft updated as well as 
the minute. If so, update the hour and the minute on the 
displayed clock. 

3. Otherwise, update only the minute on the displayed 
clock. 

4. Return to the simulation. 

CHECKBT (CHECK BuTtons) employs the following algorithm: 

1. Check: have any buttons been Jiit in the? past half 
second? 

2. If not, return to the simulation. 

3. If so, change the displayed square associated with the 
button to a triangle. (This indicates to the use,c Ui«t the 
button has been hit and " '""*"' " ; *'' "*" v "'-•" -• 



that the routine associated with the 

) Then d^e^a^l^e J|w Ju^to^ 
e hit while its associated roul 

with the hit button. Finally, when execution of the r< 



button is being executed .) Then 4M*fMtH l 4}&9<i!9f t ¥).-4<> 
that the button cannot tie hit while its associated rou 



routine 
: la ted 
routine 
is terminated, restore T ^h«^a^a^m,aA^^sem^^z« ; the. 
button. Return to the simulation. 



A. 12 The Button Protocol 

Since button handling is critical ^making TIGERS interactive, 
a button protocol has been implemented which makes it relatively easy to 
create buttons of various types. Currently three. types of buttons 
exist: 
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1. Unlabeled buttons 

2. Labeled buttons 

3. Labeled buttons with value 

Every button — regardless of type — is a single HUDDLE picture, and 
every button has associated with it a single routine. Whenever the 
button is hit the associated button servicing routine is executed. Two 
aain data bases are associated with the buttons: PICVECT is a vector of 
all the buttons, and 5ERVECT is a vector of all the button hemjling 
routines. Each element Of PICVECT is associated wlWr Wt : element of 
SERVECT. ^ 

Unlabeled buttons appear siaply as sttuarer. ikr 3 text string is 



associated with the button as part of the saae picture, although 
external labels are generally added. Examples of this type are the 
squares above th« ntninrs us«d for cr e ati n g : felt** 'tiGti&ti'tih Ifeld^fy Mode. 

Labeled buttons have a text string associated with the square as 
part of the saae picture . Examples of this type of button are the 
buttons used for changing nodes . 

Labeled buttons with value have text strings representing values 
of some variable associated wi til ttie button. Eitaa^les of ^this type are 
all the buttons in the top half of the screen frf^dify Hod*. 

The function *toftt&l c¥elt#s ^bWttiBi^of s f^Ni^; 'kii^Hntiion 
BUTTON2, buttons of type 1; and the function BUTT0N3, buttons of type 3. 
A naaing protocol has been implemented which aids in associating text 
strings, values, and service foncttons witn their associated buttons. 
We will riot discuss the details of "this prtitdtfol in tM i document, but 
we will give an example of a call to a Duttdn creating function. This 
should communicate a general idea of how the protocol is useful. The 
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call 

<BUTT0N3 -375 200 BLAHBDA .QLAHBDA .QVLAMBDA 28 > 
creates the button in Modify Node which is associated Willi the arrival 
rate LAMBOA. (-37S ZOO) «re the %xyl&(&nmm*i*** ef^tbe center Of the 
square; BLAMBDA is the name of the button; QLAHBDA is the name of the 
identifying text string; QVLAMBDA is the name of the text string 
associated with the value of LAMBDA; and 28 is the index of BLAMBDA' s 
position in PICVECT and RLAHBDA's position in SERVECT. RLAMBDA is of 
course the associate button servicing routine. 

A. 13 The Button Servicing FubcUobs 4 ^ ?i 

As of this writing there are tweatynine buttons in TIGERS. It 
is the purpose of this section to describe their ffltftjifias by discussing 
their associated handling routines. We will not describe every routine 
individually, since there are groups of similar routines. We will, 
however, discuss in detail at least one Member of each "equivalence 
class." 

A . 13.1 SIMULATE Mode — RSTART , RSTOP 

RIMITIALIZE, RSTATOH, USTATOPF ^ ) 

RSTART was difceuSsad in Section 4,2.2,, RCOWTlMtJE.e following: 

1. Call START (Section A. 6. 2). 

2. Call NPASS (Section A. 9). 

3. Initialize the count of executed events. - 

4. Enable the clock updating routine. - -4£iT»..acause -a* to be 
executed at every half second clock interrupt.) 

5. Call SIMULATE (which is an infinite loop). 



i«-3S. .^;-.'» ifeS?*^se*gT : :' ■:■ 
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RSTOP stops the simulation. It has three steps: 

1. Set 5T0PBIT to T. This causes an exit froa the infinite 

'• loop in SIMULATE. ■■ . v !i , '^r--- .v--vK -'UhoF ri * ;};...-' <vy. •»/ * 

2. Disable the clock -updating retfttA*. s 41 ^sltPWPciajaj,;--; 
it froa the clock interrupt.) 

3. Set the variable STOPSTIHE to be equal to the current 
simulated ^ time; '\;o%A.r.u ., :.. m v^.v ^ , 

RCONTINUE continues the sianlation after Its having been stopped 
by RSTOP. It does the following: 

1. Set LASTIHE to the current absolute real tiae. 

2. Set LASTHIH to the value of »«fe^piiBn|pti|^^»fi j§ - 1? 
3.' Enable the clock epdattogtreotiees. r.^iJrw ^-m- 

l'"- ' 4/ Call SlHtttAIE. •'•■ ■•'■• *t.;t ?:«.*'•■ *>:< m<sos? zuii ~o 3**jr-"-'> 

RINITIALIZE resets the simulation to tiae zero. It does nothing 

aore than call REINIT (Section A. 6. 2) and NPA5S (Section A. 9). 

RSTATON displays the cumulative statistics. 

RSTATOFF erases the cumulative statistics froa the display. 

■•'0[;:S ,TMT5S -• eboN 3" r A.iUHia_ ^ £1-A 
A. 13.2 Changing Modes — RHODIFY aMtRKiaa . TOTATaa' '_', X*l JA m if i Ji 

■ ^f ^^ItHDWIW.aJlia^a^lMvie^^iiMmia^mtfiW ta?*tad*<*> ? Jhi»/*iiMPlves 

the following: Is.-. A .;-,•<' ?^--^ ? I.HrtV-si .*; . 

1. Call RSTOP (Section A. 13.1). .' \ ^ju:;^, SA ? H .[fr."> ' 

2. Call RERASE (Section A. 13,3 X- lv tmoi x.is ssa^uy 

3*£ Eraaa taatriiaplay. , -n-. :-:jc-s e»iJs* c ---3H .«o.U' ed* 9i«u^3 .1- 
4. Display the pictures of Modify Mode. 



mode: 
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RRTSF1 (Return To Simulate Node) changes nodes back to Simulate 

1. Set STOPBIT to FALSE. This will cause SIMULATE, when 
started, *o low um.il STOPBIT ~ls> reiet *e T Sty R5TOP. 

2. Call NPA3S (Section A.9)4 ^ 
J. Erase the display. 

4. Display the pictures of Simulate mode. 



A. 13.3 Creating Text Stri ng s -- « < j 

Rl, R2, R3, .... RO, R. , RERASE 

This section discusses the buttons which comprise the 

"blackboard" in Modify Mode. The following variables are relevant: 

CURSTR - Current text**i*U*g. TM* i^th* irtr^nd^at is 
displayed above the ■ blackboard* buttons . Th% Wser builds 
this string using the blackboard. ^ i r 

CURVAk - floating point value represented by the current 
text string =.■■:--"■■-.;,* . so "^ ; - ■■■ :*-■■■•■ 

The routines -for Rl through RO and R. are similar. We describe! Mherw the 
algorithm for Rl: 

1. Append "1" to the current string. 

2. Update the display to reflect the change. 

3. Set CURVAL to the floating point number represented by 
the new current string. 

RERASE sets CURSTR to "" (the empty string), updates the display 
to reflect the change, and sets CURVAL to f-ALSE. 
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A. 13.4 Buttons With Values 

This section is concerned with the buttons which are used for 
altering the parameters of the TIGERS model. As< of th£s Writing th»re 
are nine — which buttons exist depends ujjon whit* pmremefcers the 
experimenter wishes to vary. The buttons currently imp 1 —fin ted are as 

follows: • - . ;->. -;'•:' 

BDRS - used to choose number of emergency room doctors in 
the model system. 

BNRS " used to choose number of nurses. 

BONCL - used to choose number of doctors on call. 

BTYPE - used to select the current type of Hodify Node. 
Certain, parameters vary with type of patient* the best 
example being ^e ^rtvaar*t« (^pAtie^^ to the *y*t em. ; 
The value displayed of any of th«*a tyjw ^apefldeat^ , n - ._, 
parameters is the value associated wit* the current type. 
Whenever t&* current, tyjw i» ctMUHjed,^e ; di*plia«4 values 
of these parameters are changed appropriately. <n >> ? 

BXRT - used to choose mean time spent by patient of current 
, ^typj* at x-fjjsy ; ( ■ . : r.«. r ; .5 ■..-,<-. j/ .{ .xiiii r v: r~ -eh ./,..- - 

BLT - used to choose mean time for return of lab analyatis- 
report for patient of current type. 

BSCL - used to choose ratio of simulated time to real time. 

err. r*n <;;-;} i:ssli-»'t oi fAiqe.ifa c-.'i? siifit :'-> i 
BBEDS - used to choose number of beds in the main treatment 

room. 1 .-,... ■ ■ ■■ v -, r-- r.r ? ,-i t : Av'si h ." ".- , 

BLAHBDA - used to set arrival rate of patients of the 
current type to the system in persons per hour. 

The functions associated with .e^a^e^^bi^Ansafrm^.sia^a^^iir 
that the first thing they do is check to see if CURVAL has a value other 
than FALSE. If it does not, the phrase "CHOOSE NEW VALUE" is displayed 
to indicate to the user that he should use the blackboard to assign a 
value to CURVAL. In our descriptions below of the algorithms, we 
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assume that CURVAL has in fact been assigned a value. 

RDRS, RNRS, RONCL, and RTYPE are similar. We choose a 
representative example, and elucidate below the algorithm for RDRS: 

1. Set the flag in CNTSTR which Indicates that a change has 
been made in the number of emergency room doctors , 

2. In CNTSTR, set the number of doctors equal to the value 
of CURVAL (rounded off to the lowest integer). 

3. Reset CURSTR to the empty string. 

4. Reset CURVAL to FALSE. 

5. Update the displayed values of CURSTR and the number of 
doctors to their new values. 

RXRT, RLT, and RLAHBDA form another equivalence class. The 
displayed values associated with these three functions all depend upon 
the current type (selected using BTYPE). Except for the fact that the 
current type affects the actual variable that is changed, these three 
routines are similar to the four discussed above. RBEDS differs from 
the four only in that instead of merely changing a certain value, a 
whole new picture has to be compiled based upon the new number of beds. 
RSCL differs only in that instead of changing a value directly, it calls 
CHAMGESPEED (Section A. 10). 
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APPENDIX B; 
SAMPLES OF MUDDLE S6URCE CODE 



The purpose -of this appendix is simply to give the reader an 
idea of what HUDDLE looks like. Following are listings of the two 
functions PRFD and ASSIGN. They are flowcharted in Figures A-6 and A-7, 
respectively. " ''"""- 



< DEFINE PRFD () 

<PRINT "PRFD"> 
<PROG () 

<PUT .CPATNT 3 0> 

<cond ««*? z <<* <z .cp/cnrr? z> .bedstr» 

<RETURN #>) 
(<0? <VAL .$$&» 
< COND ( < LE T ^VAL ^WQJL» 
<UPD 3 4> ' 

<adt«i DR*d .ewfrfrfy 

<ADTOf DSKJ .RT> 
«ft#$ftif 1» 
w f<1.E? <VAL .NONCL» 
<UPD 3 4> ! ~ r ' 
<ADTOQ DRO :C#KTNT> 
<ADTOQJ»Q .Rf> 
<RETURifr Z>t H: - ' 
(ELSE 
^UPD 3 8> 
<3ttBl .NONCL> 
<SEf TEV FRNCL>)>) 
(ELSE " 

<St»l -NDR> "^ ' -•'■>' ' 

<UPD 3 6> 

<SET TEV FRDR>)> * 
<ASSIGN .CPATNT> il 

<SET TTIHE <- .TTIHE 1*> 

<PUf vCIM&fr 4 <* <6 -}&Km> <~ IWlHE .RT>» 
<ADSCD .TTIHE <FORH .TEV>>»* 



<DEFINE ASSIGN (CPAT "AUX" LAB) 
<PRINT * ASSIGN" > 
<PROG () 

<TOT .CPAT 1 <♦ 1 <1 .CPAT>» 
<COND «««? <1 .CPAT> 1> 
<COND (<EXIT1?> 



mmm^M&m^r-i^j-j&'fiSsst 
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<SET TTJHE <+ .RT, <BRHtEX>» 
<COND (<NUREX?> 

<ADSCO .TTIIIE 

.CPAT> 
>n ^RETUIUi a |»> 
<ADSCD*.TTIHE *<KL&i> .CPAT> 

<&ttMir 2»> 

<COMD «S£T LAB <LAB7» 

<ADSCD <♦ .RT <LABT» 
•<UBRET> 
.CPAT> 
<UPD 2 2 .CPAT> ( "ic 

<ADD1 .LABaL>)> -vw tv**^ 

<COND (<XR?> r ^ 

<PUT .CPAT 3 L> , • -, 
<AWCft <5RT tfufc <♦ -** T ^W£T>» 



<RETyRtl 73>)> , , 
<PUT .CPAT 3 t> , 

as. mpfE'rc^ 

•,« #^^>.LAB <DRHXLT» 

i;ii 4v v=^Owaw-T»>» 

«<PRFD> 
<RETURN 3>) u T( 

««? <r:cpA^2^^ ' q , 

<COND (<CNSllTf> '-,;'". 

<ADSCD<^S|T;|#IE <♦ .RT <DRCHT>» 

< ^mm> 

<RETURH 4>)> -j 
<ADSCD <SET TTIHE <%^T <m^>» 
'<OUT> <S £ q U „> 

.CPAT>,/<3;>fH V3T 132: 

<RETURN 5» aim- ID. H.)I33A> 

(<■«? <1 .CPAT>i3> : v -> ? H ;-n f,, 

'<ifNR)S3'i. ilflOi.> 3HITT. a-i?,;^ ■ 
.CPAT> 
<RETURN 6>) 
(ELSE <ERROR T00-HAHY-D0CT0R-VISIT5>)»> 

i?AJ J 'XUA" TA r D; tiCIili. 
( } 00511 
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